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

[Roland Mainz]

Keith Whitwell wrote:
> Roland Mainz wrote:
> > CVSROOT:      /cvs/xorg
> > Module name:  xc
> > Changes by:   gisburn at gabe.freedesktop.org    05/01/04 14:05:09
> >
> > Log message:
> >   2005-01-04 Roland Mainz <roland.mainz at nrubsig.org>
> >     * xc/programs/glxgears/glxgears.c
> >     Bugzilla #2220 (https://bugs.freedesktop.org/show_bug.cgi?id=2220)
> >     attachment #1630 (https://bugs.freedesktop.org/attachment.cgi?id=1630):
> >     Make glxgears a better GL client via calling |glFinish()| between frame
> >     swaps to avoid that the GL instruction queue gets spammed, sometimes
> >     even killing all interactive usage of the Xserver.
> 
> Please don't do this - this is not "better" or reccomended GL usage.

Uhm... why ? Multiple GL experts claimed that X11R6.8.0 glxgears is
"broken" (based in the internal feedback from
https://bugs.freedesktop.org/show_bug.cgi?id=1793) and suggested either
an event-driven application model or to call at least |glFinish()|. The
first option wasn't possible (which would be preferable here as both
client and Xserver can run "decoupled" but still avoiding that the
client can send rendering instructions faster then the server can handle
them) as it seems to require GLX 1.3 so I used |glFinish()|.

> 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... ;-().

----

Bye,
Roland

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