On Tue, Mar 25, 2003 at 10:51:05PM +0000, Keith Whitwell wrote: > 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.
If there's any architectural reason why we can't use XFree86's module loader for OS indepence here ? The whole point of the drmCommand*() interface is that it's portable, so I don't see any reason to use OS specific functions like dlopen in this case. Unless there is some quantifiable reason. Alan. ------------------------------------------------------- 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
