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

[Keith Whitwell]

Roland Mainz wrote:
> Keith Whitwell wrote:
> [snip]
> 
>>>>>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.
> 
> 
> Well, at least QuakeII doesn't cause this problem (I didn't test GLquake
> yet) ...

Indeed - see my other message, the use of display lists in glxgears mean 
that it is well suited to exposing the problem in indirect renderers 
because it emits a very compact GLX stream, indicating that it is likely 
  to be the server's GLX protocol buffering that is the culprit.

Quake is a good way of demonstrating the problem in direct rendering 
drivers because it is well optimized for that type of interface, in an 
analogy to how glxgears is well optimized for an indirect rendering 
environment.

> 
>>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.
> 
> 
> How do you deal with the problem that even the libX11 buffer may be "too
> large" in this case ? You can't really reduce that buffer size so a
> different approach is needed here...

Buffering commands in libGL.so is unlikely to be a problem for system 
useability - I can't see how adding bytes to a buffer in an application 
somewhere on the system is going to affect the responsiveness of the X 
server running in an entirely different process.

(Also you probably won't get much buffered clientside for glxgears 
because as we all know glXSwapBuffers includes an implicit glFlush() 
operation which will empty those buffers...)


>>>>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.
> 
> 
> OK, what else should I do here ? There have been several complaints that
> glxgears current (X11R6.8.x) behaviour is broken (to a point where it's
> inclusion into a distribution has been rejected) so I fix is needed. As
> the problem affects Solaris, AIX and Xorg/MESA a fix within glxgears
> sounded the best way for me (as almost every GL implementation I have
> currently access to is then "broken" by ajax's definition (on IRC)).

Repeat after me:  glxgears is not broken.

There is no need to do any sort of syncing or flushing after calling 
glXSwapBuffers.  If the X server can't handle that command stream, then 
the X server needs to be fixed.

Also, the problem in the bug you reference is just temporal aliasing, 
and has nothing to do with the stability problems we've been discussing. 
  Please don't tell me that at this point you're going to bait and 
switch to a discussion of why the gears don't seem to be going around in 
smooth circles or sometimes appear to be moving backwards...

> 
>>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.
> 
> 
> Well, originally the problem didn't exist until I changed that after
> X11R6.7.0 via removing |XSync()|. So the best solution may be to restore
> the original Xfree86 and Xorg X11R6.7.0 behaviour via putting XSync()
> back - what do you think ?

That is *not* the original behaviour - someone, somewhere, for the same 
mistaken reasons put that XSync() in there to avoid fixing the real 
problem, resulting in us now once more discussing it.  You are still 
clinging to the idea that you can hide the bug in Xorg by modifying the 
test program.

For the original program, download it from its true source - 
Mesa/progs/xdemos/glxgears.c - there is no XSync(), nor should there be one.

Pl

Keith