libdrm issues blocking accelerated indirect GL

[Roland Mainz]

Jon Smirl wrote:
> > 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 ;).
> 
> Why is this so different that what a local process does right now? For
> the remote GLX user split off a new process, it uses DRI to do all of
> it's drawing and then calls back into the server for GLX. A more
> efficient scheme would be for the server to directly run GLX calls
> when received from the remote user and then ship all of the GL call
> off to the second process.

The idea of forking a complete new process worries me a lot... why is it
neccesary to use a new process here and no new thread ? A thread could
communicate much easier with the main Xserver thread than a fully-blown
new process and would even share the same memory mappings...

> Has anyone ever considered a model where the X server process forks
> off another process for each remote user, and the that process listens
> on the remote net connection and makes X/GL/GLX calls just like a
> local process, forwarding GLX/X requests to the server process as
> needed? This may be the best model for the X on GL world.

1. Doesn't this mean we will have multiple process switches just to
process the traffic ?
2. How will such a model handle applications which render in the same
window but run under different UIDs ?

----

Bye,
Roland

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