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

Tue Jan 4 16:05:39 PST 2005

Keith Whitwell wrote:
[snip]
> >>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.

What could be done within the Xorg server's GL implementation then to
get that fixed there ?

[snip]
> >>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.

I am just testing indirect rendering here...

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

OKOK... I belive you... :)

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

Erm... that was only alex's interpretation of my bug report, not what I
tried to report (yes, my original description in the bug isn't quite
usefull... ;-() ...

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

... that won't happen - a while ago a patch was added to glxgears which
gurantees a stable gear rotation rate of the gears which is independent
from the rendering frame rate. And there this mess happens: The gears
started to move "instable" on Solaris (and now it turns out that AIX has
the same problem) - not caused by temporal aliasing but by a confused
client-side timing code which wasn't able to deal with the instable
frame rate (sometimes beeing 5fps, then 17fps, then 2fps, then 11fps
etc. etc.). Putting back the |XSync();| fixed that, bringing back the
smooth rotation with a stable gear rotation rate.

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

My fault... I was only looking at the Xfree86 and Xorg sources but not
at the Mesa sources...

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

Do you have any CVSweb URL for the master repository ?

----

Bye,
Roland

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