Frequently Asked Questions

General FAQ

Technical FAQ What is OpenGL Performer?

OpenGL Performer is a powerful and comprehensive programming interface for developers creating real-time visual simulation and other performance-oriented 3D graphics applications. It simplifies development of complex applications used for visual simulation, manufacturing, simulation-based design, virtual reality, scientific visualization, interactive entertainment, broadcast video, architectural walk-through, and computer-aided design.

OpenGL Performer provides the advanced features and innovative techniques that enable you to achieve peak performance and make optimal use of system capabilities and sophisticated 3D graphics features. It gives you the capability to scale easily to multiple processors and multiple graphics pipelines, deploy to a wide range of systems and price points, and be ready-made for the graphics systems of today and the future.

OpenGL Performer is built atop the industry standard OpenGL graphics library and includes both ANSI C and C++ bindings. It forms the foundation of a powerful suite of tools and features for creating high-performance 3D graphics applications on all Silicon Graphics® systems running IRIX® 6.5 or later, 32-bit Intel® architecture-based systems with Linux, 64-bit Intel architecture-based Silicon Graphics Prism® systems with Linux, and 32-bit Intel architecture-based systems with Microsoft® Windows® 2000 or Windows® XP.

OpenGL Performer is an integral part of the SGI® Onyx® Series and Silicon Graphics Prism visualization systems and visual workstation simulation solutions from SGI and, in particular, provides interfaces to the advanced features of InfiniteReality®, UltimateVision, and Silicon Graphics Prism class graphics. OpenGL Performer is the flexible, intuitive, toolkit-based solution for developers who want to optimize performance on SGI systems.

Where can I get more information about OpenGL Performer for Linux?

A FAQ specifically related to Linux is now available at http://www.sgi.com/software/performer/linux-faq.html.

Where can I get more technical information about OpenGL Performer?

Some of the best resources for additional information are:

  • This OpenGL Performer FAQ

See below for further information and pointers to each of the above.

Where can I get more product information about OpenGL Performer?

For product information about OpenGL Performer or SGI 3D Graphics APIs contact Thomas Tannert.

More information about OpenGL Performer is also available from the OpenGL Performer WWW pages on sgi.com.

How can I order OpenGL Performer?

Contact an SGI sales representative. In the United States, call SGI direct toll-free at (800) 800-7441. If you are outside the U.S.A., contact the SGI subsidiary or authorized distributor in your area.

Also see http://www.sgi.com/software/performer/ordering.html for more information.

How does OpenGL Performer licensing work?

OpenGL Performer 3.x uses a node-locked, run-time licensing scheme in all versions (IRIX, Linux, and Windows) based upon a FlexLM license key. Both the web download and CD copy of OpenGL Performer include a demo license key with certain restrictions.

License keys are available for purchase from SGI. See the Ordering Info section of our web site or contact SGI at 1-800-800-SGI-1 (in the US) for more information. If you have already purchased a full copy of OpenGL Performer, contact SGI to register your purchase and obtain your license key.

In addition to run-time licensing, other forms of licensing (OEM licenses, site licenses, etc) are available in certain cases for major accounts. Contact your sales representative for more information.

Details about the license in OpenGL Performer 3.x:
  • Purchased licenses are node-locked, run-time licenses. This means one purchased license is valid for one system (e.g. one PC or one SGI host). A cluster of individual systems would require multiple licenses.
  • The (included) demo license allows complete operation of the OpenGL Performer toolkit -- no features are disabled -- but adds a "Powered by OpenGL Performer" logo banner to each frame. Purchased licenses have no such banner.
  • On IRIX and Linux, the license key itself is typically stored in /usr/share/Performer/license.dat. On Windows, typically C:\Program Files\Silicon Graphics\OpenGL Performer\license.dat
  • Licenses are OS-platform specific, e.g. a license for OpenGL Performer for IRIX is not valid for OpenGL Performer for Linux or Windows.
  • Many of the standard FlexLM end-user tools are included with the OpenGL Performer distribution in /usr/share/Performer/bin (%PFROOT%\Bin on Windows)
The OpenGL Performer www pages on sgi.com

http://www.sgi.com/software/performer/ contains links to further information regarding:

  • OpenGL Performer Overview
  • What's New in OpenGL Performer
  • OpenGL Performer Technical Information and White Papers
  • OpenGL Performer Downloads
  • OpenGL Performer Purchasing Information
  • OpenGL Performer Support Information
  • The OpenGL Performer Frequently Asked Questions list (FAQ)
  • OpenGL Performer News Clipper
How does OpenGL Performer relate to Open Inventor?

OpenGL Performer is a scene-graph based 3D graphics rendering toolkit designed to extract maximum system performance for developers of real-time visual simulations, virtual reality, and other markets, which typically require higher performance and a fixed frame rate. These applications take advantage of transparent multi-processing, scene and load management, multi-pipe capabilities, and a high degree of optimization and realism offered by OpenGL Performer. The toolkit is available for IRIX and Linux systems.

Open Inventor is designed for use in modeling and animation systems by providing a full-featured scene graph with easy X Window system integration and interactive graphics widgets. Beginning graphics programmers who would find it difficult to write programs using the graphics primitive level of OpenGL find they can quickly create 3D graphics applications using the Open Inventor Toolkit.

Both toolkits are general enough that they could be extended into the domain of the other, but the question you should consider is "What is the fundamental goal of my graphics development?" If it's easy X Window system integration, or handy graphics widgets, Open Inventor is for you. If it's brochure-level performance in advanced graphic applications for the specific domains listed above, then OpenGL Performer would be the likely tool.

What are all of the released versions of OpenGL Performer?

OpenGL Performer is scheduled to have about 1 major (3.x) release each year, updated by minor releases (3.x.y) each quarter, as necessary. Each minor release is binary-compatible (forwards and backwards) with the major release it updates. Therefore, API changes, new features, and removal of obsolete features can only be made in major releases. (Note: IRIS Performer™ was renamed OpenGL Performer beginning with the 2.4 release.)

No further releases of OpenGL Performer are planned for IRIX® 6.4 or earlier, Red Hat® 7.3 or earlier, or Microsoft® Windows NT®. Current and future releases of OpenGL Performer (2.5 and beyond) on IRIX platforms are planned for IRIX 6.5 and above only.

Releases to date:

3.2:An all-platform release of OpenGL Performer, including support for the Silicon Graphics Prism; support for the new OpenGL® 2.0 standard and the OpenGL Shading Language; a reworked pfCompositor API & greatly enhanced support for the SGI Scalable Graphics Compositor; new automated scene graph optimization functions in libpfdu; and further enhancements to the Maya® exporter plug-in. For all IRIX graphics systems running IRIX 6.5 or later, 32-bit Intel architecture-based systems with Linux, 64-bit Intel architecture based systems with the SGI ProPack™, and 32-bit Intel architecture-based systems with Microsoft Windows 2000 or Windows XP. Released November 2004.
3.1:An all-platform release of OpenGL Performer, including new features for programming the GPU on the Silicon Graphics® Onyx4™; a new implementation of cliptexture emulation optimized by the GPU; parametric curves, parametric surfaces, and subdivision surfaces, for manufacturing applications; and an experimental Maya® 4.5 plug-in to export datasets to PFB. For all IRIX graphics systems running IRIX 6.5 or later, 32-bit Intel architecture-based systems with Linux, and 32-bit Intel architecture-based systems with Microsoft Windows 2000 or Windows XP. Released January 2004. OpenGL Performer 3.1 has had one update since its release:
3.1.1:A full update release available on CD and the web. Released in May 2004.
3.0:An all-platform release of OpenGL Performer, the first to include support for Windows OS-based platforms. For all IRIX systems running IRIX 6.5 and later, and a standard 32-bit interface running Linux and/or Windows NT, Windows XP, or Windows 2000. Released December 2002. OpenGL Performer 3.0 had had two updates since its release:
3.0.1:An eoe & demo maintenance web release for all platforms. Released in March 2003.
3.0.2:A full update release available on CD and the web. Released in June 2003.
2.5:(Obsolete) An all-platform release of OpenGL Performer. For all IRIX systems running IRIX 6.5 and later, and Pentium® based systems running Linux. Released November 2001.
2.4:(Obsolete) An all-platform release of OpenGL Performer. For all systems running IRIX® 6.2, IRIX® 6.3, IRIX 6.4, IRIX 6.5, and Pentium based systems running Linux. Supports OpenGL only. Released November 2000. OpenGL Performer 2.4 has had 2 updates since its release:
2.4.1:An eoe & demo maintenance upgrade available for IRIX systems only. Released May 2001 with IRIX® 6.5.12.
2.4.2:An eoe & demo maintenance upgrade for IRIX systems, as well as a full update release for Linux available for web download. Released August 2001.

2.3:
(Obsolete) The first Linux release of IRIS Performer. For all Pentium based systems running Linux. Released November 1999. OpenGL Performer 2.3 has had 1 update since its release:
2.3.1:An full update release available for web download. Released May 2000.

2.2:
(Obsolete) An all-platform release of IRIS Performer. For all systems running IRIX 6.2, IRIX 6.3, IRIX 6.4, and IRIX 6.5. It supports both IRIS GL and OpenGL. Released December 1997. OpenGL Performer 2.2 has had ten updates since its release:
2.2.1:An eoe-only update release shipped on the IRIX 6.5 Foundation #2 CD.
2.2.2:A binary-compatible eoe-only bug-fix upgrade of IRIS Performer™ 2.2.1, shipping with the IRIX® 6.5.1 overlay and also available for prior IRIX releases as Patch 3229.
2.2.3:A binary-compatible eoe-only bug-fix upgrade of IRIS Performer™ 2.2.2, shipping with the IRIX® 6.5.2 overlay.
2.2.4:A binary-compatible eoe-only bug-fix upgrade of IRIS Performer™ 2.2.3, shipping with the IRIX® 6.5.3 overlay.
2.2.5:A binary-compatible eoe-only bug-fix upgrade of IRIS Performer™ 2.2.4, shipping with the IRIX® 6.5.4 overlay.
2.2.6:A binary-compatible eoe-only bug-fix upgrade of IRIS Performer™ 2.2.5, shipping with the IRIX® 6.5.5 overlay.
2.2.7:A binary-compatible eoe-only bug-fix upgrade of IRIS Performer™ 2.2.6, shipping with the IRIX® 6.5.7 overlay.
2.2.8:A binary-compatible eoe-only bug-fix upgrade of IRIS Performer™ 2.2.7, shipping with the IRIX® 6.5.8 overlay.
2.2.9:A binary-compatible eoe-only bug-fix upgrade of IRIS Performer™ 2.2.8, shipping with the IRIX® 6.5.9 overlay.
2.2.10:A binary-compatible eoe-only bug-fix upgrade of IRIS Performer™ 2.2.9, shipping with the IRIX® 6.5.10 overlay.

2.1:
(Obsolete) InfiniteReality specific full release, for all InfiniteReality systems running IRIX® 6.2 or later (eoe and dev). Released March 1997.

2.0:
(Obsolete) All-platform release for IRIX® 5.3 and later releases. Released December 1995. OpenGL Performer 2.0 had four updates since its release:
2.0.1:(Obsolete) bug fix upgrade for 2.0 EOE update only, shipped in IRIX 6.2
2.0.2:(Obsolete) bug fix upgrade for OpenGL Performer 2.0.1/2.0 eoe and dev, shipped in patches 1347(eoe)+1392(dev) (for IRIX® 6.x) or patch 1414 (for IRIX® 5.x)
2.0.3:(Obsolete) performer_eoe 2.0 bug fix upgrade, shipped with IRIX 6.3
2.0.4:(Obsolete) performer_eoe 2.0 bug fix upgrade, shipped with IRIX 6.4 and also available for prior IRIX releases as Patch 1696

1.2/IRIX5:
(Obsolete) for IRIX 5.2, 5.3, 6.0.1, 6.1. Released April 1994.
1.2/IRIX4:(Obsolete) for IRIX 4.0.5(A-J) only. Released April 1994.
1.1:(Obsolete) for IRIX 5.x only
1.0:(Obsolete) for IRIX 4.x only; the original IRIS Performer

Patch 3229:
OpenGL Performer 2.2.2 upgrade from 2.2/2.2.1; replaced 3138
Patch 3138:General fixes for performer_compat 2.2.
Patch 3018:Security fix for performer_tools 2.2. replaced 3004
Patch 3004:(recalled)

Patch 1696:
performer_eoe updates OpenGL Performer on IRIX 6.2 and 6.3 to the 2.0.4/2.1.2 shipped in IRIX 6.4. It updates 2.0.1, 2.0.2, 2.0.3 eoe to revs equiv to 2.0.4. It updates 2.1, 2.1.1 eoe to revs equiv to 2.1.2. Replaces 1347.
Patch 1414:performer 2.0 eoe and dev patch for IRIX 5.3 only
Patch 1392:performer_dev 2.0 patch for IRIX 6.2, 6.3, 6.4
Patch 1347:performer_eoe 2.0.1 patch for IRIX 6.2 only

Note that much of the above list is included only for completeness' sake. All users should upgrade to the latest version.

What version of OpenGL Performer should I use?

OpenGL Performer 3.2 is the latest all-platform release.

Binary-compatable minor-version updates to OpenGL Performer will be available with future IRIX 6.5.x maintenance and feature overlays as well as SGI ProPack releases, or on the website. As these are released we encourage all users to upgrade to the latest.

What is new in OpenGL Performer 3.2?

  • Support for the Silicon Graphics Prism, SGI's Visualization System for 64-bit Linux

    OpenGL Performer 3.2 provides support for the Silicon Graphics Prism , SGI's groundbreaking visualization system combining the world-leading Linux scalability found in the SGI® Altix® high performance server products with Intel® Itanium® 2 processors and ATI® graphics processors.

  • Support for OpenGL 2.0 and the GLSL

    OpenGL Performer 3.2 provides two new classes, pfShaderProgram and pfShaderObject, which encapsulate the functionality associated with the vertex and fragment programs used by the GLSL. A pfShaderObject is represented by a string containing the shader source code and a shader type. A collection of pfShaderObjects can be assembled to form a valid pfShaderProgram, which can then be used as a state element used by pfGeoState via the PFSTATE_SHADPROG attribute.

  • New Scene Graph Optimizer functions in libpfdu

    The new functions pfdMergeGraph, pfdStripGraph, and pfdSpatializeGraph provide a powerful pipeline of operations to reformat and optimize the OpenGL Performer scene graph for peak performance on a given hardware platform. Optimizations include re-stripping all primitives, reordering to improve cache reuse, merging short triangle strips, and several steps to properly spatialize the graph. A new "gopt" psuedoloader is also provided to enable these optimizations without code changes.

  • Reworked pfCompositor API

    The SGI Scalable Graphics Compositor option is a hardware device that combines multiple video inputs to produce a single video output. The video inputs can be divided spatially or blended together to form the final image. The pfCompositor API has been completely revamped in support of the SGI Scalable Graphics Compositor option for Silicon Graphics Onyx4 UltimateVision and Silicon Graphics Prism systems.

  • Reworked pfGeoArray API

    The pfGeoArray (short for "Geometry Array") is a new OpenGL Performer data structure aimed at replacing the existing pfGeoSet. GeoArrays allow the user to define new sets of attributes, in addition to the standard vertex coordinates, normals, texture coordinates, or colors. These attributes can be used by vertex or fragment programs applied to the primitives (see pfVertexProgram and pfFragmentProgram). Also, GeoArrays are rendered using vertex arrays and vertex objects making the rendering much more efficient. pfGeoArray can be many times faster than pfGeoSet. In OpenGL Performer 3.2, the pfGeoArray API has been revamped to reflect design improvements for the use of shaders and other libpr objects.

  • Alias Maya Exporter Enhancements

    The Alias Maya exporter has been enhanced in OpenGL Performer 3.2. It now supports Maya versions 4.5 and 6.0, provides limited export capability for animation and camera motion, and can recover topology information in models composed of NURBS and other parametric surfaces.

  • Topology Builder

    A new topology generation utility "topobuilder" has been added. This utility can automatically detect shared boundaries between adjacent surfaces.

What is new in OpenGL Performer 3.1?
  • Parametric Curves & Surfaces - New node types have been added corresponding to the opRep class heirarchy of OpenGL Optimizer™. This includes support for 2d & 3d curve & surface types and related classes
  • The PFB, CSB, and Open Inventor loaders have been updated to support the new data types. Pseudoloaders exist to modify tesselation parameters at load time. Many other utilities and samples have been added.
  • Subdivision surfaces - The new node type pfSubdivSurface has been added for Loop and Catmull-Clark subdivision surfaces. A subdivision surface is specified by a control mesh consisting of a set of connected faces, usually triangles or quads. The control mesh is stored as a pfMesh.
  • Small object culling - Small object culling is an automatic Level-of-Detail technique which removes objects from the scene whose projected size (in screen space) is less than a user-defined threshold. This can be added in user programs as a Cull Program, and 'perfly' now includes a "Cull Smaller Than" slider in the FOV panel.
  • Clip-Texture Emulation - A new implementation of Clip-Texture emulation has been added. The new emulation mode overcomes most of the limitations of the basic emulation mode, such as texture scintillation and geometry tessellation requirements. This new mode is automatically selected on systems with ARB_fragment_program support. The basic cliptexture emulation mode is selected on all other platforms (except on InfiniteReality, where hardware cliptextures are used).
  • pfGeoArray : Vertex Array support - The pfGeoArray (short for "Geometry Array") is a new OpenGL Performer data structure aimed at replacing the existing pfGeoSet. GeoArrays allow the user to define new sets of attributes, in addition to the standard vertex coordinates, normals, texture coordinates, or colors. These attributes can be used by vertex or fragment programs applied to the primitives (see pfVertexProgram and pfFragmentProgram). Also, GeoArrays are rendered using vertex arrays and vertex objects making the rendering much more efficient. pfGeoArray can be up to 10 times faster than pfGeoSet.
  • Support for Vertex & Fragment Programs - Vertex programs and Fragment programs are used by the GPU to modify various parameters of each vertex or fragment (pixel), respectively, as they are being rendered. Such programs are a sequence of assembly-like instructions defined by the GL_ARB_vertex_program and GL_ARB_fragment_program extensions to OpenGL. Performer 3.1 supports these extensions using the new state elements pfVertexProgram and pfFragmentProgram. In addition, the class pfGProgramParms is used to set changing parameters used by the programs.
  • Maya Exporter - The Maya Exporter is a plug-in for Maya 4.5 that exports Maya content to Performer PFA and PFB file formats. The exporter currently supports basic geometry and state, as well as polygon meshes, nurbs and subdivision surfaces.
  • CATIA® v4 converter - The "cat2pfb" utility provides a run-time conversion from CATIA v4 format files to Performer PFB. CATIA v4 must be installed to use the converter.
  • Support for Floating-point textures has been added.
  • Support for Red Hat® 9.0 had been added
  • Support for gcc2 has been removed from the Linux version. Only gcc3 is supported.
  • Integration with OpenGL Shader™ has been removed from all versions
  • Support for the MIPS® O32 ABI has been removed from the IRIX version. Only N32 and N64 are supported.
What is new in OpenGL Performer 3.0?

OpenGL Performer 3.0 extends many of the existing features in the toolkit with some new features added as well.

  • New support for Microsoft® Windows® platforms
  • New libpfv library that provides a modular high-level infrastructure for rapid construction and extension of OpenGL Performer applications; the library contains an extensible collection of modules for display control, model manipulation, navigation, picking, and other customizations
  • New approach to Image Based Rendering (IBR) called "Image Based Rendering Proxy," which is a technique enabling simplified ("proxy") versions of a complex object to be combined with Image Based Rendering to create incredibly realistic yet low-cost LODs
  • Additional Image Based Rendering enhancements for mip-mapping in traditional IBR models, new fast-blending modes and control of the camera positions when capturing IBR objects.
  • New cull helper process called Cull Sidekick, which allows the application to use spare CPU resources to further refine the results of the OpenGL Performer CULL process; additional calculations, such as per-primitive frustum culling, backface culling, etc., can be performed on geometry which passes the normal tests, thereby reducing the rendering load further for the DRAW process
  • Further extensions to the Cull program functionality first introduced in OpenGL Performer 2.5 to enable occluded objects to be culled from the scene
  • Support for controlling the Onyx® InfinitePerformance™ Compositor including the ability to perform dynamic load balancing on multiple pipes based on the OpenGL Performer stress functionality
  • Direct integration of OpenGL Shader™ 3.0 including the ability to use OpenGL Shader "isl" objects natively in OpenGL Performer
  • Integration with OpenGL Multipipe™ SDK providing a reader for the configuration file format. Support for Onyx® InfiniteReality4™
What are the major components of OpenGL Performer?

OpenGL Performer consists of two main libraries, libpf and libpr, and six associated libraries, libpfdu, libpfdb, libpfui, libpfutil, libpfx, and libpfv.

The basis of OpenGL Performer is the performance rendering library libpr, a low-level library providing high-speed rendering functions based on pfGeoSets, efficient graphics state control using pfGeoStates, and other application-neutral functions.

Layered above libpr is libpf, a real-time visual simulation environment providing a high-performance multiprocessing database rendering system that takes best advantage of OpenGL symmetric multiprocessing CPU hardware. Note that beginning with OpenGL Performer 2.5, libpf and libpr are actually combined into a single file in the installation. However the logical distinction between the two still remains.

The database utility library libpfdu provides powerful functions for defining both geometric and appearance attributes of three-dimensional objects, encourages sharing of state and materials, and generates efficient triangle strips from independent polygonal input.

The database library libpfdb uses the facilities of libpfdu, libpf, and libpr to import database files in many popular industry-standard database formats. These loaders also serve as a guide to developers creating new database importers.

The libpfui library contains user interface building blocks for creating manipulators and user-interface components common to many interactive applications. This library has both a C and C++ API and is OpenGL GL/OpenGL independent.

The experimental viewer class library libpfx provides an easy-to-use interface for creating basic OpenGL Performer applications.

The modular viewer library libpfv provides a high-level infrastructure for rapid construction and extension of OpenGL Performer applications. It ships with an extensible collection of modules for display control, model manipulation, navigation, picking, and other customization.

Completing the suite of libraries is libpfutil, the OpenGL Performer utility library. It provides a collection of convenience routines implementing tasks such as smoke effects, MultiChannel Option support, graphical user interface tools, X and OpenGL GL event collection and management, and traversal functions.

For aid in application development, OpenGL Performer includes sample application source code ranging from simple programs to illustrate particular features to the comprehensive, GUI-driven file viewer perfly.

Does OpenGL Performer use IRIS GL or OpenGL?

OpenGL Performer 2.3 and all subsequent versions support OpenGL only.

IRIS Performer 2.2, 2.0.4, 2.0.3, "2.0.2," 2.0.1, and 2.0 contain bindings for O32 IRIS GL, O32 OpenGL, N32 IRISGL, N32 OpenGL, and N64 OpenGL.

IRIS Performer 2.1, 2.1.1, and 2.1.2 uses OpenGL only, having bindings for O32 (32-bit) OpenGL, N32 (32-bit) OpenGL, and N64 (64-bit) OpenGL.

IRIS Performer 1.0, 1.1, and 1.2 use IRIS GL (32-bit).

Guaranteeing real-time performance (IRIX systems only)

  • Run as root so that OpenGL Performer can lock your process to a particular CPU (if using pfuLockCPU) and give it a nondegrading priority.

  • Be sure to kill any clocks, gr_osview, or other tools that may wake up and draw themselves, so as to avoid graphics context switches.

  • When multiprocessing, make sure the executable is on a local filesystem.

  • There is a new real-time kernel directive for Onyx® and Challenge® processors for directing system interrupts away from real-time processors.

    In the file /var/sysgen/system/irix.sm, search for NOINTR and below the comment explaining NOINTR, add the line

      NOINTR: 1 2 3 4 etc.

    where you list the CPUs that you intend to do real-time processing on. Then reboot. This can be done on 5.2+ Onyx or Challenge systems but wasn't covered in the base IRIX®5 documentation. Be sure not to specify CPU 0, as you will want it to be available for necessary interrupts.

  • With IRIS GL, real-time performance can only be guaranteed if you have one window rendering at a time per pipe.

    If more than one application is rendering to the same hardware pipeline, the (hardware) graphics pipe has to switch back and forth between each OpenGL GL window's context several hundred times per second. This is horribly inefficient and the graphics pipe will instruct the "other" process to block while its context is switched out.

  • Since having other (CPU-based) applications running can also affect real-time performance, it's sometimes desirable to minimize the number of daemons and other processes. If you have problems achieving real-time behavior, try the pfuLockCPU in libpfutil. You might also try turning off the desktop support and other daemons that are not crucial to your application, e.g.:
      % touch ~/.disableDesktop
      or
      % mkdir ~/.desktop-<machinename>
      % touch ~/.desktop-<machinename>/nodesktop
    and for total removal do:
      % chkconfig desktop off
      % chkconfig objectserver off
      % chkconfig directoryserver off
      % chkconfig fontserver off
      % chkconfig soundscheme off
How do I make OpenGL GL calls from within an OpenGL Performer program?

OpenGL GL calls can only be made from a process that has a OpenGL GL context. In multiprocess OpenGL Performer applications only the draw process has OpenGL GL context, so you must make your OpenGL GL calls in a function called in the draw process.

The pipe initialization callback, draw function callback, and node draw callbacks are all executed in the draw process.

In an application that only will ever run single-process, OpenGL calls can be made from anywhere in the program, but this is considered a dangerous practice.

To set up a pipe initialization callback, see the pfInitPipe() manpage. To set up a draw function callback, see the pfChanDrawFunc() manpage. To set up a node draw callback, see the pfNodeTravFuncs() manpage.

How do I overlay graphics on top of my OpenGL Performer scene?

Typically this is done to implement a heads-up display (HUD).

In the draw function callback, the basic algorithm is:
    save state with pfPushState()
    disable textures, fog, and lighting with pfBasicState()
    save andclear projection matrix
    ortho2()
    save & clear modelling matrix
    draw()
    restore modelling matrix
    restore projection matrix
    restore state with pfPopState()

Or you can draw your static information in the overlay planes and only redraw it when the window receives a REDRAW event (moved, resized, etc.). Changing between drawing to the overlays and drawing to regular bitplanes takes a big hit.

For things that need to be updated in real time, draw() would consist of:
    zfunction(ZF_ALWAYS);
    zwritemask(0x0);
    draw HUD stuff
    zfunction(ZF_LEQUAL);
    zwritemask(0xffffffff);
What is the difference between phases FREE, LIMIT, FLOAT, and LOCK?

PFPHASE_FREE_RUN and PFPHASE_LIMIT maintain full synchronization among APP CULL and DRAW. This means that every APP frame has corresponding CULL and DRAW frames. These phases are useful for simple graphic programs.

PFPHASE_FLOAT and PFPHASE_LOCK let CULL miss APP frames, and let DRAW miss CULL frames. This means that if CULL is too slow, APP may produce more than a single frame before CULL is ready. CULL always takes the latest ready frame and skips all previous ones. Similarly, CULL may produce more than a single frame before DRAW is ready. DRAW always picks the latest ready frame from CULL and skips all previous ones. These phases reduce the latency between the latest APP frame to the rendered DRAW frame.

PFPHASE_FREE_RUN wakes the APP and DRAW processes up on the next video field boundary after the DRAW process finishes. It's the OpenGL Performer version of the usual run as-fast-as-I-can or as-slow-as-I-must mode that most simple graphics programs use.

PFPHASE_LIMIT wakes the APP and DRAW processes up on the next video field boundary after the DRAW process finishes, but no earlier than the requested frame rate. It is very similar to PFPHASE_FREE_RUN, but never runs faster than the requested frame rate. It is useful for programs that run at a steady frame rate but have a few quick frames.

PFPHASE_FLOAT wakes the APP up only on frame boundaries, i.e., time = n*(1/frame_rate). However, the DRAW process "floats" with respect to the frame rate, wakes up on the next possible field boundary, and then calls swapbuffers() when it's done, regardless of whether it finished drawing in time for the desired frame rate. Hence you see every frame that's drawn to the backbuffer, but it may not appear at exactly the time for which it was planned. If you never frame extend, it behaves like PFPHASE_LOCK.

PFPHASE_LOCK wakes the APP and DRAW up only on frame boundaries and only swaps on frame boundaries. The advantage is that each new image always appears at precisely the time for which it was rendered. The disadvantage is that if the DRAW process runs even slightly over a frame time, you skip that entire frame and are stuck with an outdated picture for an entire frame.

For more information see the pfPhase() man page or section 7.1.2 of the OpenGL Performer Programming Guide.

Use of PFTMPDIR to configure shared memory (IRIX)

OpenGL Performer requires shared memory and uses a memory-mapped file, the location of which depends on the value of the PFTMPDIR environment variable.

If PFTMPDIR is not set, OpenGL Performer uses /dev/zero as the default. Running an application in this configuration:
  • Uses swap space
  • Does not require disk space until main memory is exhausted
  • Is faster than using a regular memory-mapped file via PFTMPDIR
  • Causes IRIX to kill the process(es) and log an error to the console if the application runs out of space for shared memory in the swap partition
If PFTMPDIR is set, OpenGL Performer creates files in the specified directory. Running an application in this configuration:
  • Requires disk space even before main memory is exhausted
  • Is slower than /dev/zero because it touches the disk
  • Produces appropriately sized core dump files with no limit set by OpenGL Performer
  • Might cause a core dump from a segmentation violation inside pfMalloc if the application runs out of space for shared memory in the filesystem containing PFTMPDIR
  • PFTMPDIR should be set only to a directory on a local filesystem