libdrm issues blocking accelerated indirect GL

[Adam Jackson]

On Friday 31 December 2004 09:56, Felix Kühling 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...)

> Cons: GLX protocol goes through the same channel as X protocol. So doing
> GLX in a separate process would involve forwarding GLX protocol from the
> Xserver to the real GLX server process in some way. Not sure how much
> overhead in time and code complexity that would introduce.

I'm not sure either.  I'd take it as a given that people using indirect 
rendering are willing to sacrifice some performance, but they shouldn't be 
made to suffer more than necessary.  We do have something resembling this in 
the form of DMX's glxProxy, but I don't know how much work would be required 
to split that out into a helper process.  I assume it's doable though.

The higher issue is that enabling the X server to also be a DRI client is work 
that needs to happen for X on GL anyway.  That statement doesn't invalidate 
the glxProxy approach: The Xgl server could translate core X11 (and 
Render/Xv/...) to GL and feed all drawing requests to the glxProxy.  Which 
would be a rather interesting subversion of the X design.

So I guess I don't have any hard arguments against that approach.  The soft 
argument would be that doing indirect GL in the server reduces overall 
component count, whereas the proxy approach is trading GLcore for glxProxy.

Or, to quote the horse from Ren and Stimpy, "No sir, I don't like it." ;)

They're not mutually exclusive, though.  There might be value in doing both, 
in-server DRI for maximal performance versus glxProxy for more stability in 
the face of driver bugs.  If you design the API right pluggability wouldn't 
be too hard.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20041231/b620a25d/attachment.pgp>