Rob Jenkins (robj++at++quid.csd.sgi.com)
Mon, 26 Jan 1998 08:03:04 -0800
PF Warning/Internal: pfGetVClock: failed with GLX error 0x5.
Is that the problem you had ? I'm going to paste a full description of this
problem and the solution at the end of this mail ( it also effects OCTANE +
latest gfx patch). In short though, the problem is worked around in performer
2.2 so I would recommend contacting your local SGI office to get 2.2 and
reinstall the patch.
If you have irsaudit showing HW problems then you should also make sure you
have the latest iR diagnostics patch ( patch 2440 ), rerun irsaudit and if you
are getting errors then log a support call for that also.
Cheers
Rob
On Jan 24, 2:09pm, Stephan Braun wrote:
> Subject: Re: Performer 2.1 on Onyx2
> I had problems with pfClock when I installed the patch2326.
> I heard that this patch is more suitable for Performer 2.2. Is this
> true?
>
> The Xserver is less stable than before. Sometimes it seems that a
> hardware error happens when you run irsaudit and you can watch other
> funny things. :(
>
> I removed the patch.
>
> Regards
> Stephan
> --
> Stephan Braun
> Max-Planck-Institute for office: +49 (0)7071/601-631
> Biological Cybernetics fax: +49 (0)7071/601-616
> Spemannstr. 38 e-mail: miles++at++mpik-tueb.mpg.de
> 72076 Tuebingen, Germany web: http://www.mpik-tueb.mpg.de
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>-- End of excerpt from Stephan Braun
-------------------------------------------------------------------------
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
SOFTWARE RELEASE
IRIX(tm) 6.4 with either patch 2326 , 2193 , or 2771
REFERENCE
This problem is being addressed in bug 553293.
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.
--
________________________________________________________________
Rob Jenkins mailto:robj++at++sgi.com
Silicon Graphics, Mtn View, California, USA
=======================================================================
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:37 PDT