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) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) ------------------------------------------------------- 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