Rob Jenkins (robj++at++quid.csd.sgi.com)
Wed, 31 Dec 1997 09:19:57 -0800
Allan Schaffer posted this advance warning about a regression in patch 2326
recently, I thought I'd follow it up now that the problem/impact/solution is
clearer. In the context of Performer it's simple, running with pf 2.2 ( MR, not
Beta ) has no problems. The text below describes situations that would have the
problem and also has some background on the OpenGL cause of the problem in case
any of you have OpenGL stuff outside Performer that could be bitten by the bug.
If you have any problem that sounds like this and it's not covered below then
please let me know.
Cheers
Rob
------------------------------------------------------------
Patches 2326, 2193, and 2771 cause multipipe programs to hang
MODELS AFFECTED
Multipipe Onyx2(tm) InfiniteReality(tm) with patch 2326
and OCTANE(tm) dual-head with patches 2193 or 2771
DESCRIPTION
Patches 2326: "Onyx2 6.4 graphics rollup #3 including GVO and DVP2
support", 2193: "6.4 Impact Graphics fixes," and 2771:
"6.4 Impact Graphics fixes" contain a regression that causes multipipe
programs to fail.
Note that patch 2326 is specific to Onyx2 InfiniteReality systems
and IRIX 6.4, and patches 2193 and 2771 are specific to OCTANE(R)
systems only. The only programs affected by this regression are those
running in multipipe mode.
Only these patches (2326 , 2193 , 2771) are known to have this problem.
The current graphics roll-up patch for Onyx/6.2/InfiniteReality systems
(patch 1808) does not have the regression. Likewise, prior
graphics roll-up patches for Onyx2 and OCTANE systems did not experience
the problem.
RESOLUTION/RECOMMENDATION
Patch 2326 and Patch 2771 are still in the 12/1/97 recommended patch
sets for Onyx2 and OCTANE systems, respectively because they contain
other important fixes. Single-pipe systems should not be affected by
the problem and should have the appropriate patches loaded.
Patch 2193 is replaced by 2771 and should be upgraded.
For now, sites with a multipipe Onyx2 InfiniteReality system running
multipipe Performer applications should make sure they upgrade to the
released version of Performer 2.2. If they have non Performer multipipe
programs or cannot upgrade to Performer 2.2 for some reason, then they
will have to stay with patch 2191. Or, if patch 2326 is installed, then
remove it and install patch 2191 "Onyx2 6.4 graphics rollup #2
including GVO support." Be sure to follow the installation release
notes when removing or installing these InfiniteReality gfx patches;
ideally, make sure it is done from miniroot.
There will be a replacement for patch 2326 soon (patch 2789:Onyx2 6.4
graphics rollup #4 including GVO support).
Sites with dual-head OCTANE systems running multipipe Performer
applications should ensure that they upgrade to the released version of
Performer 2.2. If they have non Performer multipipe programs or cannot
upgrade to Performer 2.2 for some reason, then they will have to stay
with patch 1953 . Or, if patch 2193 , or 2771 is installed, then remove and
install patch 1953 "6.4 Impact Graphics fixes."
There is no replacement started for patch 2771 yet, although it is
likely that there will be soon.
The released version of Performer 2.2 has a workaround so that it can run
with patch 2326 , 2193 or 2771 . Note: this workaround was not in earlier
Beta versions of Performer 2.2.
APPENDIX
In the case of Performer applications, the symptoms would be that the
application will just stop after apparently trying to initialize the
pipes. With the Performer notification level set to at least 5, you will
see a message like:
5543 PF Debug: Gfx Context is not local - VClock not supported.
Another message might be:
PF Warning/Internal: pfGetVClock: failed with GLX error 0x5.
Refer to man pfNotify for details on the Performer notification level.
To force the level high enough, enter:
setenv PFNFYLEVEL 5
and then run the application from that shell.
Mark Kilgard has some comments in general:
o The problem occurs when performing OpenGL rendering (IRIS GL(tm) uses
OpenGL(R) on OCTANE and InfiniteReality systems) on a nondefault
screen of an X display connection. For example, if your DISPLAY
is set to :0.1 (default screen is screen 1) and you create a
window on :0.0 (a nondefault screen), you will be affected.
A simple OpenGL demo that just creates windows on its default
screen will not be affected.
(Please understand that ":0" indicates the X server to connect
to. An X server connection can create windows on any supported
screen. The ".0" or ".1" suffix indicates the default screen
upon which windows will be created. Understand that even when your
display is set to ":0.0", you can still create windows on screens
other than screen 0.)
o The only way an application can "notice" the bug (and hence have
problems) is if glXIsDirect is used to figure out if there is a
nondirect OpenGL rendering context or if you do some operation
that can be done only in a direct rendering OpenGL context (such
as swap barriers).
o If you do a glXMakeCurrent to a window on a nondefault screen,
you may end up using GLX protocol to send OpenGL rendering
requests to that window. If so, this would be a significant
performance hit. Unfortunately, this has not been verified.
I believe that the actual exposure to this bug is limited by these facts:
o Bug does NOT affect single-pipe machines.
o Bug affects ONLY InfiniteReality and OCTANE systems with named
patches.
o Bug matters ONLY to applications that create windows on
nondefault screens. Multipipe IRIS Performer applications definitely
do this, but few other OpenGL applications (unless specifically coded
to do so) will create windows on nondefault screens.
o To fail, the application must do something that would be allowed
on only a direct rendering OpenGL context. Examples of which I'm
aware include:
Use of GLX swap_barrier extension.
Operating incorrectly if glXIsDirect returns false.
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:56:29 PDT