[Fwd: Re: CVS Update: xc (branch: trunk)]
keith at tungstengraphics.com
Wed Jan 5 02:10:17 PST 2005
Roland Mainz wrote:
> Keith Whitwell wrote:
>>>>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
>>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 ?
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 15330 bytes
Desc: not available
More information about the xorg