Re: libdrm issues blocking accelerated indirect GL

[Keith W. <ke...@tu...>]

Roland Mainz wrote:
> Adam Jackson wrote:
> 
>>>I have a seventh option for you. Feel free to flame me if it sounds
>>>stupid ...
>>>
>>>- Option 7: Run the GLX server as a separate process forked by the
>>>Xserver. This way you get rid of the problem with the same library
>>>linked into the same process multiple times.
>>>
>>>Pros: No existing ABIs need to be changed. It would also improve the
>>>responsiveness of the Xserver when expensive indirect rendering
>>>operations are performed (for instance software fallbacks).
>>
>>This is indeed a major problem.  Indirect glxgears is extremely laggy at
>>processing user input (and worse in 6.8 than it used to be...)
> 
> 
> The current "glxgears" implementation is braindead as it spamms the
> Xserver with tons of rendering requests to rotate the gear teeth without
> waiting for any reponses. Somewhere in my queue is a patch which solves
> that using the original XSync() way (but offers a switch to turn that
> on/off on demand).
> Unfortunately it's not the whole story as the GL implementation in the
> Xserver could prevent the problem via putting itself at the end of the
> schduler queue after each frame swap. Some GL server implementations do
> that and get a _far_ better responsiveness with the current 6.8.x
> glxgears implementation than what the Xorg server currently allows.

The direct dri drivers face the same problem and solve it by throttling 
on swapbuffers to enforce a maximum number of outstanding swapbuffer 
requests at any point.  If the dri.so driver was loaded into the server, 
it would continue to behave in this way and avoid the problem without 
any additional work.

Keith