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

[Keith Whitwell]

Roland Mainz wrote:
> 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]

I thought about this a bit more last night.

The behaviour with glxgears might be resolved by looking at buffering, 
but attached is a program which does a much better job of exercising the 
problem than glxgears.  I call it 'killer_gears.c', and it will 
monopolize the X server for a quite a while when you run it against the 
indirect renderer, even after it's been killed.  (Ctrl-Alt-Backspace 
seems to work, though)

It does 1000x as much rendering per frame than regular gears, all from a 
single protocol request.  No matter how you manage the buffers, there's 
no right time to devote the X server to rendering 1000 gears frames.

So, looking at buffering is important for latency and usability of 
regular glx applications, but the system stability concerns seem to need 
deeper changes to cope with pathological applications.

I think Alan Cox's email gives the right approach - threading or 
co-routining within Mesa to solve the monopolization issues, plus an 
examination of buffering if you care about interactive latencies.

Keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: killer_gears.c
Type: text/x-c
Size: 15330 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050105/74911a41/attachment.bin>