On Fri, 31 Dec 2004 14:16:57 -0500, Adam Jackson <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
