Felix Kühling wrote: > > Am Do, den 30.12.2004 schrieb Adam Jackson um 20:20: > > The goal: Load DRI drivers from the server's libglx, rather than the > > software-based libGLcore. > > > > Currently there are four server-side modules: dri, drm, glx, and GLcore. > > There are also three client-side pieces: libGL, *_dri.so, and (uh-oh) drm. > > 'drm' here is libdrm, which lives in /cvs/dri/drm and is occasionally > > imported into X as hw/xfree86/os-support/$(uname)/drm. libdrm is identical > > on both sides, modulo wrapping some things like malloc to use either the > > Mesa > > or X version. > > > > The problem here is, libdrm is linked into each DRI driver, as well as > > loaded > > dynamically by the server. If we want the server to be able to load DRI > > drivers, then we need to make sure the two instances of libdrm don't > > conflict. So we have options here. > > I have a seventh option for you. Feel free to flame me if it sounds > stupid ... > > - 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). ---- 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
