libdrm issues blocking accelerated indirect GL

[Alex Deucher]

On Fri, 31 Dec 2004 13:17:34 -0500, Adam Jackson <ajax at nwnk.net> wrote:
> 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.
> 

glxproxy might also be a better route for adding accelerated 3d
support in conjunction with xinerama (where you may have mutliple
backend 3d engines, or even shared access to a single 3d engine)
rather than having to run dmx or something similar.

Alex

> 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
> 
>