libdrm issues blocking accelerated indirect GL

[Roland Mainz]

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

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)