libdrm issues blocking accelerated indirect GL

[Adam Jackson]

On Friday 31 December 2004 13:41, Roland Mainz wrote:
> Felix Kühling wrote:
> > - 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).

glxProxy effectively would put the GL rendering in its own thread.  And 
nothing necessarily prevents us from creating a new thread for in-server DRI.  

If the rendering is properly encapsulated, then making it multicore-friendly 
is cheap and easy; if libglx is redone such that both in-process and 
out-of-process indirect GL are possible, then the rendering is probably 
pretty close to being properly encapsulated.

Not disagreeing with you, just saying that discussion is quite a bit down the 
line ;).

- 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/833cd9ab/attachment.pgp>