[Fwd: Re: CVS Update: xc (branch: trunk)]

Roland Mainz roland.mainz at nrubsig.org
Tue Jan 4 15:11:23 PST 2005

Brian Paul wrote:
> >>The problem as such is with the driver not the application, and GL
> >>applications in general do not do this.   By hiding the behaviour in
> >>glxgears you are removing the incentive to fix the real problem.
> >
> >
> > The original behaviour (in Xorg X11R6.7.x) was to call |XSync()| which
> > was considered a ugly hack. Then I removed that for X11R6.8.x, resulting
> > in the current problem. But if you look at my patch you'll see that you
> > can get all the old behaviour:
> > % glxgears -no_glfinish_after_frame # will restore the original
> > X11R6.8.0 spam-to-death behaviour,
> > % glxgears -no_glfinish_after_frame -xsync_after_frame # will restore
> > the original X11R6.7.0 behaviour. Additionally you can ask for two other
> > methods of sync'ing (see -sched_yield_after_frame and
> > -xflush_after_frame) so everyone should be happy (well, I would prefer
> > the event-driven model but it seems someone will have to update the GLX
> > wire protocol level first... ;-().
> >
> Keith is correct, glxgears is not broken.

Umpf... the problem is that not everyone agrees with that
(sort-of-deadlock where both the client and the server party claim it's
the bug of the other party... ;-(). 

> There are probably lots of
> OpenGL apps out there that are written in the same manner.

Which one ? AFAIK most real-world application don't exhibit this
DOS-like behaviour as they are all waiting for X events at some point.

> Here's another scenario.  Suppose a GL application renders a few
> thousand large triangles that happen to require a slow software
> rendering path in the server.  The client can probably issue the GL
> commands a lot faster than the server can render them.  How would you
> propose handling that?

Well, in theory glxgears would be event-driven where the GL engine then
sends an event per buffer swap. In that case glxgears then would wait
for the event after having prepared the next frame (e.g. for(;;) {
swap_buffers() ; render_background_buffer_content();
wait_for_swap_event() ; swap_buffers(); }) - glxgears would then render
with maximum speed but wouldn't spam the server to death.



  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)

More information about the xorg mailing list