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.
The goal is to load the same piece of code in both places, so that would require that the radeon_dri.so object became an XFree86 module, and that the XFree86 module loader was also incorporated into libGL.so.
That seems like a big step, and would obviously break compatibility with older libGL.so's.
We could also compile the radeon_dri.so code as both a .so file and an XFree86 module, but that has issues of its own.
Keith
------------------------------------------------------- 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
