libdrm issues blocking accelerated indirect GL
roland.mainz at nrubsig.org
Fri Dec 31 10:41:31 PST 2004
Felix Kühling wrote:
> Am Do, den 30.12.2004 schrieb Adam Jackson um 20:20:
> > The goal: Load DRI drivers from the server's libglx, rather than the
> > software-based libGLcore.
> > Currently there are four server-side modules: dri, drm, glx, and GLcore.
> > There are also three client-side pieces: libGL, *_dri.so, and (uh-oh) drm.
> > 'drm' here is libdrm, which lives in /cvs/dri/drm and is occasionally
> > imported into X as hw/xfree86/os-support/$(uname)/drm. libdrm is identical
> > on both sides, modulo wrapping some things like malloc to use either the Mesa
> > or X version.
> > The problem here is, libdrm is linked into each DRI driver, as well as loaded
> > dynamically by the server. If we want the server to be able to load DRI
> > drivers, then we need to make sure the two instances of libdrm don't
> > conflict. So we have options here.
> 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).
> 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.
What about looking at other Unix OpenGL implementation which already
support accerlated indirect rendering ? For example Solaris implements
indirect GL rendering, offloading the GL engine in a seperate thread
(per head, e.g. dual-head will have two GL rendering threads,
tripple-head will have three threads etc.; note that the implementation
encapsulates the GLX extension in a way that the Xserver code doesn't
need to be thread-safe, only the GL engine is).
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
More information about the xorg