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

[Keith Whitwell]

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

Following up on myself, the buffer in question is most likely to be one 
containing the GLX protocol, as glxgears manages to use the 
performance-oriented features of the GLX protocol to do a large amount 
of drawing with very little actual wire traffic.  So a couple of 
kilobytes of buffering can probably contain a few hundred frames worth 
of gears output.

Changing or amending the GLX protocol isn't ever going to eliminate the 
problem as long as remote connections are allowed, as the foreign libGL 
may not use whatever protocol changes are added to get try and deal with 
this.

So you're left with dealing with this in the X server.

I see two ways of doing this:

1) Reduce the amount of GLX protocol that is buffered but not rendered 
in the X server, perhaps in response to the rate of consumption of the 
protocol stream by the backend driver.

2) Improve the scheduling of the GLX protocol stream in relation to 
other clients to avoid the situation where the indirect renderer locks 
out other clients.

Keith