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
pgpjfNM9ndruB.pgp
Description: PGP signature
