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.
- 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.
-- Gareth
------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
