Round trip query to the X server.

New Message Reply Date view Thread view Subject view Author view

Bernard Leclerc (bernard.leclerc++at++discreet.com)
Wed, 10 Nov 1999 14:36:07 -0500

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

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Wed Nov 10 1999 - 11:36:20 PST

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.