========================================================================== The checksum's (found through sum -r) of the files that you have received (other than this README) are as follows: 60066 19 patchSG0001392 38848 97343 patchSG0001392.dev_sw 36277 112437 patchSG0001392.dev_sw32 32608 62136 patchSG0001392.dev_sw64 31667 1076 patchSG0001392.idb 62125 5239 patchSG0001392.man 49164 5960 patchSG0001392.src ========================================================================== - 1 - 1. Patch_SG0001347,_SG0001392,_and_SG0001414_Release_Notes Welcome to IRIS Performer 2.0.2. This software provides bug fixes for IRIS Performer2.0 and 2.0.1 based products. It is packaged to upgrade IRIS Performer 2.0 on IRIX 6.2 and 5.3, as well as the performer_eoe portion of IRIS Performer 2.0.1. IRIS Performer 2.0.1 EOE is shipped with IRIX 6.2 and is included as a compatibility subsystem for IRIS Performer 2.1. To handle all the upgrade combinations, there are three separate patches: IRIS Performer Patch SG0001347: This patch supplies the performer_eoe subsystem of Performer 2.0.2. It is only for IRIX 6.2. Use this patch to upgrade the performer_eoe part of Performer 2.0 or Performer 2.0.1. It will upgrade the EOE part of Performer if you've installed Performer 2.0, or the 2.0.1 compatiblity subsystem that's part of Performer 2.1. If you are running IRIX 6.2 and using Performer 2.0 or 2.0.1, you should install patch SG0001347. This patch includes 32-bit MIPS II, III, and 64-bit MIPS III libraries and will run on R4000, R5000, R8000, and R10000 CPUs. IRIS Performer Patch SG0001392: This patch supplies the performer_dev subsystem of Performer 2.0.2. It is only for IRIX 6.2. Use this patch to upgrade the performer_dev part of Performer 2.0. It will upgrade the DEV part of Performer if you've installed Performer 2.0, or will provide the 2.0.2 performer_dev subsystem if you have Performer 2.1 (the 2.0.1 compatibility subsystem doesn't have a DEV part). If you are using IRIX 6.2, and you bought IRIS Performer 2.0, or you need the DEV part of Performer 2.0.2 for a complete 2.0.2 compatibility subsystem to go with 2.1, then you should install patch SG0001392. If Patch SG0001392 is installed, then patch SG0001347 should also be installed. This patch includes 32-bit MIPS II, III, and 64-bit MIPS III libraries and will run on R4000, R5000, R8000, and R10000 CPUs. IRIS Performer Patch SG0001414: This patch supplies both the performer_eoe and the performer_dev part of Performer 2.0.2. It is only for IRIX 5.3. It will upgrade both the EOE and the DEV parts of Performer 2.0. If are using IRIX 5.3 and you bought IRIS Performer 2.0 then you should install patch SG0001414. This patch includes 32-bit MIPS I libraries and will run on R3000, RR4000, R5000, R8000, and R10000 CPUs. Here is a table containing the above information: - 2 - IRIX Version | IRIS Performer Version | Patch to Install _____________|________________________|___________________________________ 5.3 | 2.0 | 1414(covers eoe and dev) 6.2 | 2.0 | 1347(eoe) + 1392(dev) 6.2 | 2.0.1 eoe with 2.1 | 1347(eoe) or 1347(eoe) + 1392(dev) These three patches all fix the same bugs in IRIS Performer. The release notes cover all three patches. This document contains the following chapters: 1. Introduction 2. Installation Information (see note on disk space!) 3. Bugs fixed from Performer 2.0 and 2.0.1 4. Known Problems and Workarounds 1.1 Special_notes_for_IRIS_Performer_2.0.2 Performer 2.0.2 includes the fast loading database loader, libpfpfb, originally released with Performer2.1. The pfconv program to convert other file formats to pfb is shipped as part of the demo subsystem. A fast loading version of the Performer Town is included in the general data subsystem and a shell script to run perfly on this database is in the demo subsystem and is installed as /usr/share/Performer/data/town/RUNTOWN.sh. Performer 2.0.2 includes the Active Surface Definition library, libpfs, released originally with Performer2.1 as part of the "common" subsystems. This library provides an advanced method of defining, reconstructing, and displaying geometric objects with variable resolution. One use of this support is in large-area terrain rendering where the hierarchical level of detail nature and user directed morphing allow high-quality visualization with selectable polygon density. Refer to the pfTerrain reference page for more information. If you are installing the IRIS Performer 2.0.2 developement environment from patch 1392 or 1414 and are developing for IMPACT graphics, take note of an improved texture downloading utility included in the performer_dev.src.sample subsytem, installed as /usr/share/Performer/src/lib/libpfutil/tex.c.IMPACT. This version of the texture loading functions has much better - 3 - IMPACT memory utilization and we recommend that libpfutil be rebuilt with tex.c.IMPACT replacing tex.c if libpfutil will be run on IMPACT. The changes should have little effect on other graphics platforms. 1.2 Supported_Hardware_Platforms These patches will run on any systems running the corresponding required versions of IRIX. 1.3 Supported_Software_Platforms IRIS Performer Patch 1347 updates all of IRIS Performer 2.0(.X) eoe (versions 1009000170-1232792133) running on IRIX 6.2, including IRIS Performer 2.0.1 (version 1232792133) shipped with IRIX 6.2 and including the 2.0-2.0.1 compatibility subsystems shipped in IRIS Performer 2.1 (version 1234000053). IRIS Performer Patch 1414 updates IRIS Performer 2.0 (version 1009000170) on IRIX 5.3. This software cannot be installed on other configurations. IRIS Performer 2.0.2 is binary compatible with Performer 2.0 and contains fixes for the bugs listed in the following section. If you want to install Performer 2.0 onto a system with Performer 2.0.2 eoe, please do not install Performer 2.0 eoe subsystems. The minor version number of the IRIS Performer 2.0.2 DSOs has been incremented so that the new version number is sgi2.2 and can be differentiated from that in the 2.0 and 2.0.1 DSOs using 2.0 and 2.1, respectively. 1.4 Product_Support Silicon Graphics, Inc., provides a comprehensive product support maintenance program for its products. To get support for this product, contact your local support provider. 1.5 Getting_IRIS_Performer The IRIS Performer execution environment is provided to allow the execution of IRIS Performer applications without a purchased copy of IRIS Performer. However, you may want to buy the IRIS Performer product for its development environment, tools, demos, sample applications, and - 4 - databases. The full IRIS Performer product includes sample application source code ranging from simple programs to illustrate particular features to the comprehensive, GUI-driven file viewer perfly. In addition to these SGI-developed tools, IRIS Performer also includes a very large repository of sample code, databases, games, and movies contributed by the Friends of Performer: companies and individuals with services of general interest to the IRIS Performer community. To find out more about IRIS Performer visit our web page at http://www.sgi.com/Technology/Performer/. To purchase a copy of IRIS Performer contact your local sales office. - 1 - 2. Installation information for Patch SG0001347, SG0001392, and SG0001414 2.1 Special_Note_for_those_running_IRIS_Performer_2.1 The Performer2.0.2 DSOs are included in compatibility subsystems to update the 2.0-2.0.1 compatibility libraries that were shipped in IRIS Performer 2.1. If you are running IRIS Performer2.1, you need only install the "compat" subsystems listed below. The other subsystems aren't required. These subsystems are: patchSG0001347.compat.performer2_0_2 IRIS GL and OpenGL DSOs patchSG0001347.compat32.performer2_0_2 IRIS GL and OpenGL DSOs (n32) patchSG0001347.compat64.performer2_0_2 IRIS GL and OpenGL DSOs (n64) 2.2 Subsystems_for_updating_IRIS_Performer_2.0-2.0.X Several subsystems comprise the IRIS Performer 2.0.2 patch distribution. These subsystems are not all required for a proper installation. Note that this patch software will only update existing subsystems. This means that the base subsystems from IRIS Performer 2.0 (or IRIS Performer 2.0.1) must be on the system in order to sucessfully install the patch. If your system is tight on space, especially in the root partition, adding the patch can be difficult. See the note regarding disk space at the end of this chapter for hints on installing on tight systems. There are OpenGL and IRIS GL versions of the GL-specific Performer libraries -- these are the two GL-types supported by this release. This Performer environment supports both optimized (compiled "-O2" for performance) and debug (compiled "-g" for full symbol table and stack trace support) versions of each dynamic shared object (DSOs or ".so" files). This environment also spans two machine architecture levels -- the 32-bit MIPS I/II instruction set and the 64-bit MIPS - 2 - III/IV instruction set -- along with two versions of 32-bit support -- the old caller-save register management protocol known as Old-32 (O32 is used by all current IRIX 5 programs) and the newer callee-save register management protocol termed New-32 (N32) -- there are actually three versions of each library: O32, N32, and N64. The file2 IRIX shell command can tell you what version of the MIPS instruction set is being used by a given executable. The multidimensional complexity of all these library formats is hidden within IRIS Performer since the APIs for all these formats are the same. The subsystem naming conventions are designed to be simple and regular: o Old-32 32-bit libraries are the default and are in ".sw" subsystems. These are marked for default installation. o New-32 32-bit libraries are in ".sw32" subsystems. These are only useful on IRIX 6.2 and later operating system releases. o New-64 64-bit libraries are in ".sw64" subsystems. These are only useful on IRIX 6.2 and later operating system releases. o IRIS GL libraries have ".igl" subsubsystem name components. For best performance, use IRIS GL on RealityEngine and all previous graphics systems. o OpenGL libraries have ".ogl" subsubsystem name components. For best performance, use OpenGL on Impact and all subsequent graphics systems. o Optimized libraries are the default and have no special name. For best performance, always use the optimized Performer libraries. The debug versions of the libraries have the word "debug" in their names. A few simple examples should make this clear. These examples hold for all patches so we use 'XXXX' for the patch number. o patchSG000XXXX.sw.igl_performer: O32, IRIS GL, Optimized, DSO - 3 - o patchSG000XXXX.sw32.ogl_performer: N32, OpenGL, DSO o Note that this example illustrates a subtlety not mentioned in the rules above -- since only OpenGL is supported in 64-bit modes, all GL-specific 64-bit subsystems are inherently OpenGL in nature. IRIS Performer patches SG0001347 and SG0001414 update IRIS Performer eoe subsystems whose names were composed following the conventions outlined above: patchSG000XXXX.eoe_sw.demo Demos patchSG000XXXX.eoe_sw.data Sample Data and Fonts patchSG000XXXX.eoe_sw.asddata Sample Data for the Active Surface Definition Library (new) patchSG000XXXX.eoe_sw.common_performer GL-independent DSOs patchSG000XXXX.eoe_sw.igl_performer IRIS GL DSOs patchSG000XXXX.eoe_sw.ogl_performer OpenGL DSOs patchSG000XXXX.eoe_sw32.common_performer GL-independent DSOs (n32) patchSG000XXXX.eoe_sw32.igl_performer IRIS GL DSOs (n32) patchSG000XXXX.eoe_sw32.ogl_performer OpenGL DSOs (n32) patchSG000XXXX.eoe_sw64.performer DSOs (n64) IRIS Performer patches SG0001392 and SG0001414 update IRIS Performer dev subsystems whose names were composed following the conventions outlined above: patchSG000XXXX.man.c Performer2.0.2 C Man Pages - 4 - patchSG000XXXX.man.c++ Performer2.0.2 C++ Man Pages patchSG000XXXX.man.common Performer2.0.2 Non-Language-Specific Man Pages patchSG000XXXX.src.loader Performer2.0.2 Loader Code patchSG000XXXX.src.sample Performer2.0.2 Sample Code patchSG000XXXX.dev_sw.common_debug_performer Performer2.0.2 GL-independent Debug DSOs patchSG000XXXX.dev_sw.common_debugstatic_performer Performer2.0.2 GL-independent Debug Static Libraries patchSG000XXXX.dev_sw.common_static_performer Performer2.0.2 GL-independent Static Libraries patchSG000XXXX.dev_sw.hdr Performer2.0.2 Headers patchSG000XXXX.dev_sw.igl_debug_performer Performer2.0.2 IrisGL Debug DSOs patchSG000XXXX.dev_sw.igl_debugstatic_performer Performer2.0.2 IrisGL Debug Static Libraries patchSG000XXXX.dev_sw.igl_static_performer Performer2.0.2 IrisGL Static Libraries patchSG000XXXX.dev_sw.ogl_debug_performer Performer2.0.2 OpenGL Debug DSOs patchSG000XXXX.dev_sw.ogl_debugstatic_performer Performer2.0.2 OpenGL Debug Static Libraries patchSG000XXXX.dev_sw.ogl_static_performer Performer2.0.2 OpenGL Static Libraries patchSG000XXXX.dev_sw32.common_debug_performer Performer2.0.2 GL-independent Debug DSOs (n32) patchSG000XXXX.dev_sw32.common_debugstatic_performer Performer2.0.2 GL-independent Debug Static Libraries (n32) patchSG000XXXX.dev_sw32.common_static_performer Performer2.0.2 GL-independent Static Libraries (n32) - 5 - patchSG000XXXX.dev_sw32.igl_debug_performer Performer2.0.2 IrisGL Debug DSOs (n32) patchSG000XXXX.dev_sw32.igl_debugstatic_performer Performer2.0.2 IrisGL Debug Static Libraries (n32) patchSG000XXXX.dev_sw32.igl_static_performer Performer2.0.2 IrisGL Static Libraries (n32) patchSG000XXXX.dev_sw32.ogl_debug_performer Performer2.0.2 OpenGL Debug DSOs (n32) patchSG000XXXX.dev_sw32.ogl_debugstatic_performer Performer2.0.2 OpenGL Debug Static Libraries (n32) patchSG000XXXX.dev_sw32.ogl_static_performer Performer2.0.2 OpenGL Static Libraries (n32) patchSG000XXXX.dev_sw64.debug_performer Performer2.0.2 Debug DSOs (n64) patchSG000XXXX.dev_sw64.debugstatic_performer Performer2.0.2 Debug Static Libraries (n64) patchSG000XXXX.dev_sw64.static_performer Performer2.0.2 Static Libraries (n64) 2.3 Installation_Instructions Because you want to install only the patches for problems you have encountered, patch software is not installed by default. After reading the descriptions of the bugs fixed in this patch (see Chapter 3), determine the patches that meet your specific needs. If, after reading Chapters 1 and 2 of these release notes, you are unsure whether your hardware and software meet the requirements for installing a particular patch, run inst. The inst program does not allow you to install patches that are incompatible with your hardware or software. Patch software is installed like any other Silicon Graphics software product. Follow the instructions in your Software Installation Administrator's Guide to bring up the miniroot form of the software installation tools. Follow these steps to select a patch for installation: - 6 - 1. At the Inst> prompt, type install installable patchSGxxxxxxx where xxxxxxx is the patch number. If you list the subsystems in the patch, the ones labeled NX can't be installed because the corresponding base subsystem isn't on the system. The subsystems labled NA can be installed because the corresponding base software is present. The install command above marks all NA software subsystems for installation. If you don't want them all, then use inst in the usual way to selectively mark only the subsystems you want. 2. Initiate the installation sequence. Type Inst> go 3. You may find that two patches have been marked as incompatible. (The installation tools reject an installation request if an incompatibility is detected.) If this occurs, you must deselect one of the patches. Inst> keep patchSGxxxxxxx where xxxxxxx is the patch number. 4. After completing the installation process, exit the inst program by typing Inst> quit 2.4 Patch_Removal_Instructions To remove a patch, use the versions remove command as you would for any other software subsystem. The removal process reinstates the original version of software unless you have specifically removed the patch history from your system. versions remove patchSGxxxxxxx where xxxxxxx is the patch number. To keep a patch but increase your disk space, use the versions removehist command to remove the patch history. versions removehist patchSGxxxxxxx - 7 - where xxxxxxx is the patch number. 2.5 Special_Note_for_those_running_IRIX5 The 5.3 installation tools have trouble installing into linked directories, particularly for new files. Our data subsystems, eoe_sw.data and eoe_sw.asddata, include new files that were not in Performer 2.0(.1) and the installation of these subsystems will fail if /usr/share/Performer/data is actually a link to another disk or file system. The installation will fail with an error about non-existent files in the target file system. 2.6 Note_on_New_Subsystem_eoe_sw.asddata A patch subsystem will be uninstallable if its base subsystem from Performer 2.0(.1) was not previously installable. However, the new subsystem, eoe_sw.asddata, had no previous base subsystem and will appear uninstallable. To install this new subsystem, set the rulesoverride resource to true. Do not attempt to install other subsystems unless a valid base subsystem as already been successfully installed. Doing otherwise may lead to an unusable environment; in which case a forced install of Performer2.0.(1) will put things back to a workable state. 2.7 Note_on_Disk_Space When a patch is installed, the files being replaced are backed up with their root file structure under /var/inst/patchbase/. This is done to support possible future removal of the patch and may take up substantial disk space as it must make a copy of the current IRIS Performer subsystems. You may want to copy the contents of /var/inst/patchbase/ to a separate filesystem that has sufficient room to hold the files, then make a link from the /var/inst parent directory to the copied patchbase directory. Take a look in the tar man page for a good way to copy directory structures. - 1 - 6. Bugs_Fixed_by_Patch_SG0001347,_SG0001392,_and_SG0001414 The IRIS Performer 2.0.2 libraries are binary compatible with IRIS Performer 2.0 and 2.0.1 (shipped with IRIX 6.2). There were some problems in the 2.0 libraries that were fixed for the 2.0.1 execution environment and those, plus some additional bug fixes are included in the IRIS Performer 2.0.2 libraries. The minor version number of the IRIS Performer 2.0.2 DSOs has been incremented so that the new version number is sgi2.2 and can be differentiated from that in the 2.0 and 2.0.1 DSOs. 6.1 IRIS_Performer_2.0_Problems_fixed_in_2.0.1_and_2.0.2 o OpenGL Fog: OpenGL exponential fog in IRIS Performer 2.0 did not match the IRIS GL fog and has been corrected. (bug #338726) o OpenGL request for TAG clear on InfiniteReality caused OpenGL errors (bug #342228) o OpenGL default MIPmapped Texture filter: Graphics platforms that should be using MIPMAP_TRILINEAR as the default minification filter (such as RealityEngine and IMPACT) were actually using MIPMAP_LINEAR in 2.0. The default minification and MIPmap filter has been fixed. (bug #392320) o Detail Texture Splines: Several bugs with the specification of detail splines in IRIS Performer 2.0 have been fixed. The default OpenGL splines now match the IRIS GL defaults. Specification of clamped detail splines for IRIS GL operation have been fixed. (bug #339589) o OpenGL Detail Texture on IRIX 6.2: OpenGL detail texture through IRIS Performer 2.0 was not functional when running under 6.2 and has been fixed. (bug #392259) o OpenGL Texture Loading on RealityEngine: In IRIS Performer 2.0 running under OpenGL on RealityEngine graphics, texture had to be explicitly enabled for a texture to be successfully loaded. This is now handled internally by IRIS Performer. o pfdLoadFile_flt: The FLT loader under IRIS Performer 2.0 64bit operation was core dumping and this has been fixed. (bug #392262) - 2 - o Order of pfBuffer commands executed by pfMergeBuffer() is reversed in 2.0: IRIS Performer 2.0 could core dump after pfMergeBuffer() if child nodes in the asynchronous process were created before their parents. (bug #347746) o pfDrawBin core dump: pfDrawBin() would core dump if called on an empty bin. (bug #344198) o IRIS GL windows had no stereo buffers: pure IRIS GL windows would not be configured with stereo buffers with pfWinFBConfigAtrrs() even if the PFFB_STEREO token was present in the attribute array. (bug #344181) o IRIS GL window queries were broken: some of the window config queries for pfQueryWin() would always return 0 for pure IRIS GL windows. (bug #344181) o Resizing of pfPipeWindows when multi-processed and using X windows (IRIS GLX or OpenGL/X) when an alternate framebuffer configuration window is selected (such as the fill statistics window in OpenGL/X perfly) has been fixed. In IRIS Performer 2.0 this could channel viewports to be confused when the alternate framebuffer configuration window is de-selected (such as disabling the fill statistics in perfly when running with X windows). (bug #392262) o pfAlphaFunc had no effect if PFSTATE_ENLIGHTING is being overridden (bug #319457) o pfMatrix::getOrthoCoord: Performer2.0 it gave bad roll when pitch was +-90. (bug #334615) o C++ perfly error: In the C++ perfly and related programs, on multipipe machines, all windows get opened on pipe 0. The fix is swapping lines 419 and 420 in perf/sample/apps/C++/common/generic.C. (bug #335105) o Intersections with PFGS_POLYS could cause core dumps in Performer2.0. (bug #346482) o Memory corruption by extending pfStrings by 1 character: (bug #346502) o Bad malloc for names of pfFonts: this could potentially cause a core dump in Performer2.0 o pfTextures could not subload MIPmap levels (bug #334345) - 3 - o pfGetTexBorderColor did not work in Performer2.0. (bug #332384) o Reflection mapping with the Inventor loader: files loaded through libpfiv could not properly use reflection mapping in Performer2.0. (bug #324961) 6.2 IRIS_Performer_2.0_and_2.0.1_Problems_fixed_in_2.0.2 o N32 core dump in in _pfDirtCheck and _pfLightDirtCheck: Due to an N32 compiler bug, N32 applications with more than 256 textures or lights could core dump in _pfDirtCheck or _pfLightDirtCheck. A work-around for this problem is in 2.1 and 2.0.2. (bug #399553) o pfTextures with source of PFTEX_SOURCE_VIDEO did not work under OpenGL operation. This has been fixed in 2.0.2 and in 2.1. (bug #396077) o Internal format for 1 and 2 component textures: defaulted to 12 bits for the intensity component which causes inefficient memory usage on IMPACT. o pfTexture reference counts incremented after pfLoadTex() in libpf apps: pfTextures that are loaded with pfLoadTex() or pfSubloadTex{Level} could get their reference count artificially incremented in libpf applications. (bug #392273) o pfDelete with forked DBASE process: asynchronous pfDelete of data allocated off the heap and not in shared memory could cause core dump. (bug #392274) o pfFlatten on indexed pfGeoSets could cause core dump. (bug #365204) o pfLPointStates using textures for light point shape generated an incorrect default texture for the shape of the light. (bug #392317) o pfMatrix::makeVecRotVec() gave a bad matrix on opposite vectors: When the input vectors were pointing in opposite directions, a matrix was returned that represented a uniform scale of -1, which is not a rotation. This has been fixed in 2.0.2 and 2.1. (bug #402541) o C++ perfly had randomly bad flight model behavior: The C++ perfly example source code had the call to pfSync() commented out in main.C and this caused problems with - 4 - the flight model when intersections are run in a separate process (bug #402637). - 1 - 4. Known_Problems_and_Workarounds This chapter lists the current problems with the IRIS Performer 2.0 + 2.0.2 libraries and with the shared memory configurations. 4.1 IRIX6 o Statistics: The PFSTATSHW_CPU pfStats statistics class for accumulation of statistics on CPU usage are not yet implemented for IRIX6 operation (64bit or 32bit). o When building executables on IRIX 6.2 and linking directly using ld rather than implicitly via CC, an alarming number of warnings about tables that are defined in multiple .so's may be printed. These are harmless but the appropriate compiler option to disable the warning has not yet been identified. The problem does not occur when linking with CC, which is identical in function and serves as an effective workaround. o pfInitClock() on 250MHz IMPACT: The clock period determined by pfInitClock() on 250MHz IMPACT systems is apparently inconsistent with the true clock period. It seems that the actual clock period is that of a 200MHz system. Consequently, pfGetTime() will return a time that is .8 (200/250) that of the true time. As a workaround, you can specify an alternate clock period with the PFCLOCKPERIOD environment variable. If set, PFCLOCKPERIOD specifies the clock period, in picoseconds, to be used by pfInitClock(). For proper behavior on 250MHz IMPACT systems, use 40000 for the period. (bug #326421) 4.2 IRIX5.3 o When building static OpenGL executables in IRIX 5.3 installed it may be necessary to specify the "- ignore_unresolved" option to ld since not all OpenGL extensions used in Performer are available on all platforms and OS versions. You may see warnings for the unresolved symbols of OpenGL extensions that are not present on the current system, but the executable will still successfully link. o When moving a window on Extreme graphics under IRIX 5.3 in some clear modes the Z-buffer may not be updated - 2 - properly until a full czclear() operation is performed. 4.3 Graphics Hardware and OpenGL Issues o When more than 512 textures are used in either IRIS GL or OpenGL the hardware and or host-side software may become confused and in some cases, may falter completely and terminate the application. This is a graphics library limitation. o IRIS GL based Performer 2.0 executables may encounter difficulties when executing multipipe on dual-head Indigo systems. This problem is not present in OpenGL applications. Check with SGI Customer Support for the latest advice if you encounter this problem and need to use IRIS GL rather than OpenGL. o The video rate used by IRIS Performer for frame rate control is computed at application startup on some machines and is not always exactly correct. If this is a problem, the video rate can be set with pfVideoRate. o Although Performer supports it, OpenGL does not support different material color modes for front and back materials. When Performer encounters this case, it disables the material color mode for the back material. o Antialiasing: When it is not multisampling, pfAntialias can significantly degrade performance. Specifically, on non-RealityEngine systems, use pfAntialias only for lines and points. o Coplanar polygons: pfDecal works only on machines that support the stencil or displacepolygon command. The default decaling mode for PFDECAL_BASE uses displacepolygon instead of stencil. This can significantly improve rendering performance but can result in visual anomalies where layer polygons incorrectly "poke" through other geometry. If you wish to use stencil then specify the PFDECAL_BASE_HIGH_QUALITY token. o Stencil: stencil is used for PFDECAL_BASE_HIGH_QUALITY and for pfStats mode PFSTATSHW_GFXPIPE_FILL. Stencil is not supported on all graphics platforms. Indy graphics platforms under IRIS GL operation do not support stencil. The Extreme graphics platforms support stencil with reduced depth buffer resolution so IRIS Performer will not allocate stencil bits in the default framebuffer configuration. While allocated by default, the allocation of extra stencil bits can also - 3 - affect your depth resolution and number of samples for multisample on RealityEngine graphics platforms. o Detail textures of format SUBLOAD are not properly subloaded. pfTextures that are used as detail textures and have pfTexFormats of PFTEX_SUBLOAD_FORMAT may not get their image data properly loaded into texture memory under IRIS Performer 2.0-2.0.2 and an OpenGL error may be flagged. (bug #392268) o Transparency: pfTransparency works only on machines that support either blendfunction or multisample (RealityEngine). o pfLPointState: pfLPointStates offer advanced features for the sophisticated light point primitive for visual simulation applications. Some of the texturing modes may not be supported or currently working on mid-range or low-end graphics platforms. o Frame control on low- and mid-range machines: Currently, the video clock (pfInitVClock, pfGetVClock, pfVClockSync) is supported only on systems with VGX, VGXT, RealityEngine, RealityEngine2, Elan, XS, Extreme, and Impact graphics hardware. On other systems, pfVClockSync returns immediately. Because libpf normally uses pfVClockSync for frame rate control, frame control is not rigorous on other platforms. o Since having other applications running can impact 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 utility code 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- % touch ~/.desktop-/nodesktop and for total removal do: % chkconfig desktop off % chkconfig objectserver off - 4 - % chkconfig directoryserver off % chkconfig fontserver off 4.4 libpf o pfApplyFrust() does not properly apply a frustum which has been transformed with pfOrthoXformFrust(). Instead, the canonical frustum whose eye is at the origin and is looking down the +Y axis, is applied. o pfFlatten() is broken for pfGeoSets with pfCycleBuffer attribute arrays. A core dump is likely. o The PFSTATE_LIGHTS sorting key for the PFSORT_BY_STATE mode of pfChanBinSort() is not yet implemented. o Intersection testing of line segments (pfNodeIsectSegs) against geometry in pfBillboard nodes is not yet implemented; only the bounding sphere of the entire pfBillboard is available. o Channel fade LOD attributes and mixed graphics configurations: Channel fade LOD attributes are set in the application process. The existence of multisample,required for fade LOD, is tested at the time that the attributes are set with pfChanLODAttr. This test for multisample uses the application process window system connection (pfOpenWSConnection) or else the DISPLAY environment variable to select a screen for determining graphics configuration, instead of testing the current window of the pfChannel. In a multipipe environment where one graphics pipeline has multisample and one does not, the application process needs to have a window system connection or DISPLAY that points to the pipeline with multisample, in which case the non- multisample pfChannels will try to use fade LOD. In a multi-window environment, windows without multisample on a system with multisample will try to use fade LOD. o Gangdraw and cursor loading: Loading the cursor with ganged swapbuffers (external swapready wire) hangs graphics. Workaround: don't load the cursor and use a full screen window when using ganged swapbuffers. o Timing on pre-1992 platforms: Several libpf functions require high-resolution timing information. On most recent machines (Indy, Indigo, Indigo2, 4D/35 and Onyx) and PowerSeries or Crimson machines with IO3 boards, IRIS Performer uses special hardware counters with - 5 - sub-microsecond resolution. (The IO3 board was standard on Crimson and later 4D/300 and 4D/400 machines. You can check for it with the hinv(1M) command.) On older platforms, for example, those with IO2 boards, the time-of-day clock is used, which, by default, has a 10 ms resolution. This resolution is inadequate for many libpf functions, including animation sequences (pfSequence), graphics load computation (pfChanStress), and the display of accurate channel statistics (pfDrawChanStats). On these machines, you may want to enable fast timers using systune(1M) to set the fasthz variable. See the man page for timers for more information. Frame rate control is poor on machines that lack both a fast clock and the video clock used by pfVClockSync. 4.5 libpfutil o No known problems. 4.6 libpfui o Libpfui has both a C API and a C++ API. The C API is actually wrappers around the C++ API and is not complete. 4.7 libpfdb o pfdLoadFile_dxf: The DXF loader does not fully support the format. o pfdLoadFile_sgo: The SGO loader does not support triangle strips. 4.8 Sample Programs o perfly on Indy under IRIS GL: the background of the GUI panel is influenced by the loaded database. Additionally, fill statistics are not supported on Indy under IRIS GL and will cause flashing and error messages to stderr. o pguide/libpf/C/pipewin: The overlay text is only drawn in IRIS GL and does not get properly redrawn wih the window size is changed. - 6 - o pguide/libpf/C/lpsatate: The lpstate.c example for demonstrating pfLPointStates uses sophisticated texturing capabilities that may not yet work on the IMPACT, Extreme, or Indy graphics platforms. 4.9 Notes_on_Shared_Memory_Configurations IRIS Performer requires shared memory and uses a memory- mapped file, the location of which depends on the value of the PFTMPDIR environment variable: o If PFTMPDIR is not set, 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. o If PFTMPDIR is set, 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 IRIS Performer - Might cause a core dump from a segmentation violation inside pfMalloc if the application runs out of space for shared memory in the file system containing PFTMPDIR - PFTMPDIR should be set only to a directory on a local file system.