From: Keith W. <ke...@tu...> - 2003-03-25 22:50:36
|
Gareth Hughes wrote: > Keith Whitwell wrote: > >> >> Yes, very nice. >> >> Utah did have some stuff going for it. It was designed as a >> server-side-only accelerated indirect renderer. My "innovation" was >> to figure out that the client could pretty easily play a few linker >> tricks & load that server module with dlopen(), and then with minimal >> communication with the server, do 90% of the direct rendering tasks >> itself. (This was after my first encounter with PI, I think, until >> then I hadn't heard of direct rendering). >> >> The nice thing about this was that the same binary was running the >> show on both the client and the server. That really was obvious in >> the communication between them -- all the protocol structs were >> private to one .c file. > > > That's what we do -- the NVIDIA libGLcore.so driver backend does both > client-side direct rendering and server-side indirect rendering. > libGL.so or libglx.so does the necessary work to allow the main driver > to have at it. > >> It really shouldn't be that hard. Against it are: >> >> - XFree's dislike of native library functions, which the 3d driver >> uses with abandon. > > > You can avoid these issues by using imports -- the server-side native > library function imports would just call the appropriate XFree86 > routine, while the client-side imports would just call the regular C > library versions. I think Brian added stuff like this at some point, > not sure however. Yep - I see that you could get the server to instantiate the imports & avoid the problem that way. Good. > >> - XFree's love of their loadable module format, which the 3d >> driver isn't... > > > Our libGLcore is a regular shared library (as is our libglx.so, for that > matter). Doesn't seem to be an issue, AFAIK. My impression is that a patch trying to add a dlopen() call to one of the xfree86 hosted ddx drivers would be rejected. Keith |