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

[Keith Whitwell]

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

Every GL driver can potentially exhibit this behaviour, the fact that 
none do is because it is such an easy condition to trigger and that even 
basic usage of a driver brings it to light.  If glxgears causes your 
driver to become unresponsive, think what quake will do to it.

The trouble with your fix is that it covers up a driver bug in one 
application only, namely glxgears.  It does so by doing something that 
is quite unusual for GL applications and isn't recommended or normal 
coding practice.

The real problem is that the driver does nothing to throttle the rate it 
accepts GL commands in relation to the speed of the hardware. 
Presumably there is a very large buffer somewhere which is being filled 
up with rendering commands - the simplest way to reduce the problem 
would be to find and reduce the size of that buffer.  It may be that the 
items being buffered are GLX protocol requests, or drawing requests 
internal to the X server or both, or something else entirely.

The approach taken in the accelerated drivers is to count the number of 
swapbuffers commands which have been issued vs. the number which have 
been processed and ensure that number remains small.

> 
>>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.

I agree with that assessment...

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

Unfortunately the problem remains for all the 100% minus one GLX 
applications out there in the world - by modifying glxgears you have 1) 
altered the behaviour of an application people use as a known quantity 
debugging GL installations and 2) hidden only trivially a real problem 
with indirect rendering in Xorg.

Adding a glFinish() after glXSwapBuffers() is as bad a hack as an 
XSync() in the same spot, and for much the same reasons.

This is like saying "oh, there's a bug in Xorg patterned fills, we'll 
just change xtest so that it doesn't exercise that path".  It doesn't 
work because real applications that people use will also trigger the 
behaviour.

Keith