libdrm issues blocking accelerated indirect GL

[Jon Smirl]

On Fri, 31 Dec 2004 14:16:57 -0500, Adam Jackson <ajax at nwnk.net> 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.

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.

-- 
Jon Smirl
jonsmirl at gmail.com