On Tue, Mar 25, 2003 at 11:27:17PM +0000, Keith Whitwell wrote: > Alan Hourihane wrote: > >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. O.k. That seems like a good goal to aim for.
> That seems like a big step, and would obviously break compatibility with > older libGL.so's. I don't think it's that big a step, and the advantages are enourmous in maintenance. > 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. Indeed. 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
