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

[Brian Paul]

Roland Mainz wrote:
> 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... ;-().
> 

Keith is correct, glxgears is not broken.  There are probably lots of 
OpenGL apps out there that are written in the same manner.

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?

An application which renders frames at a very high rate (such as 
glxgears) isn't the only problematic case.  The client might be 
throttled to render frames at 60Hz but the suppose the server can only 
do 1Hz.  Same problem.

-Brian