libdrm issues blocking accelerated indirect GL
Alex Deucher
alexdeucher at gmail.com
Fri Dec 31 10:39:07 PST 2004
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
>
>
More information about the xorg
mailing list