Phil Keslin (philk++at++cthulhu.engr.sgi.com)
Wed, 10 Nov 1999 16:08:07 -0800
At present, Performer does not track the viewport state. This requires that the
viewport be reset every frame (and hence the window geometry is retrieved every
frame). We have looked at fixing this in the past, but haven't addressed it yet.
This problem is only exhibited on the O2.
- Phil
Bernard Leclerc wrote:
>
> Platform: O2, IRIX 6.5.4f, performer_dev 2.2, performer_eoe 2.2.5
>
> We all know that doing a round trip request to the X server is a NO when
> real-time and stable update rates are required. Somehow, it seems to be
> the case here. I've been able to observe this behavior with simple.C
>
> Here is how. Use "par" to monitor the system activity while "simple" is
> running. The following command will monitor system calls to "read" and
> "select" for 3 seconds and write the results into file "simple.par".
>
> $ par -s -SS -n read -n select -o simple.par -u -t 3 simple x29.sv
>
> The file is fairly long but, near the end, you'll notice a steady state
> that resemble this:
>
> 2159mS: read(7, <01 18 01 49 00>..., 32) = 32
> 2161mS: read(7, 0x7fff28c0, 32) errno = 11 (Resource temporarily
> unavailable)
> 2161mS: select(8, [7], 0, 0, 0)
> 2162mS: END-select(8, [7], 0, 0, 0) = 1
>
> Notice the "Resource temporarily unavailable" message while reading from
> file descriptor 7. Also notice that the process will go to sleep because
> of the call to select().
>
> Now if we use dbx to find out where the program calls read(), the stack
> trace looks like this (I've simplified the output to increase
> readability):
>
> (dbx) t
> > 0 __select() [".../select.s":17, 0xfafc008]
> 1 _select() [".../selectSCI.c":30, 0xfb059f0]
> 2 _XRead() [".../XlibInt.c":492, 0xf71c29c]
> 3 _XReply() [".../XlibInt.c":1858, 0xf71e368]
> 4 XGetGeometry() [".../GetGeom.c":43, 0xf6f7890]
> 5 __glXGetDrawableSize() [".../glx_direct.c":358, 0xd993bd0]
> 6 FindWindowSize() [".../crm_context.c":260, 0xda51730]
> 7 ApplyViewport() [".../crm_context.c":274, 0xda51844]
> 8 __glim_Viewport() [".../so_xform.c":555, 0xdb39ce0]
> 9 pfChannel::pf_applyView() [".../pfChannel.C":4518, 0x5860e90]
> 10 ::pfFrame() [".../pfProcess.C":6283, 0x58a5278]
> 11 ::main() [".../simple.C":144, 0x10002cd4]
> 12 __start() [".../crt1text.s":177, 0x100025d8]
> (dbx) q
>
> This is strange. If you follow the trace from level 9, you see that
> Performer calls the Open GL library to re-apply the viewport. In turn,
> OpenGL calls X to obtain the window size. THAT'S causing the round trip
> request to the X server... and that breaks the stable update rate.
>
> Ok, you're gonna say that the O2 isn't capable of real-time performance.
> I know! But I still don't see why there's a need to get the window size
> when it hasn't changed.
>
> I also tried with
>
> pw->setWinType(PFPWIN_TYPE_X | PFPWIN_TYPE_NOXEVENTS);
> pw->setFullScreen();
>
> but that didn't helped.
>
> So the question remains: why is Performer/OpenGL doing a round trip
> request to the X server when no X event has been received to justify the
> query?
>
> Is this a bug in Performer? Or is it a problem with OpenGL on O2?
>
> Note that this behavior can't be seen on the Octane. It seems to be
> specific to the O2.
>
> --
> bernard leclerc* *from discreet, a division of AutoDesk
> t 514.954.7317 10, rue duke
> f 514.393.0110 montréal (québec) canada, H3C 2L7
> mailto:bernardL++at++discreet.com http://www.discreet.com
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
-- Phil Keslin <philk++at++engr.sgi.com>
This archive was generated by hypermail 2.0b2 on Wed Nov 10 1999 - 16:08:16 PST