I'm rounding out the final bits of support for SGI_make_current_read. I've hit a (hopefully) minor snag, and I'd like some advice on how to proceede. At this point, *all* of the client-side support, both in libGL.so and in at least one driver, is in place. I'm now working on the server-side support.
My approach in libGL was to make a single "master" routine that glXMakeCurrent, glXMakeContextCurrent, and glXMakeCurrentReadSGI all call. The greatly simplified the code. I would like to duplicate that model on the server-side. My biggest uncertainty is where the API boundries are (i.e., where the binary compatability problems are). I believe that it is safe for me to modify the __GLXcontextRec (in programs/Xserver/GL/glx/glxcontext.h). I need to replace pGlxPixmap & glxPriv with separate read & draw pointers. I have also modified __glXMakeCurrent (in programs/Xserver/GL/glx/glxcmds.c) to be a new function called DoMakeCurrent that takes a client state pointer, read & draw drawable pointers, a context ID, and a context tag and "does the right thing." Things are pretty smooth up to this point.
The problem comes in gc->exports.makeCurrent (called by __glXMakeCurrent in the original code). As near as I can tell, this is set to __MESA_makeCurrent (located in programs/Xserver/GL/mesa/src/X/xf86glx.c, line 775). This function makes an "imported" call to get the current drawable and calls XMesaMakeCurrent. Herein lies the problem. I need to add a new imported called (something like getReadablePrivate) and change __MESA_makeCurrent to call XMesaMakeCurrent2.
The server-side code for MakeCurrent always struck me as being kind of weird. Instead of passing the new context and drawable to the core renderer's MakeCurrent function, __glXMakeCurrent() binds the drawable to the context (line 514), then calls the core renderer's MakeCurrent with just a context parameter.
Just by looking at how things are called, making these changes would seem to be a binary compatability problem. Is that assessment correct? It seems like I can, with a certain amount of pain and suffering, work around the problem *if* I can detect when the different binaries are expecting different interfaces. Does anyone have any advice on how to do that? Is there any way for libglx.a and libGLcore.a to tell which version the other is? Is it safe to expect that both will always be in sync?
After a quick code review, I think you'll have to add a new 'readbuffer' field to the end of the __GLXcontext struct in glxcontext.h.
Then, in __glXMakeCurrentRead (doesn't exist yet, but would wind up in glxcmds.c) you'd set that new field before calling gc->exports.makeCurrent() (i.e. __MESA_makeCurrent).
Next, I think you'll need to add a new getReadablePrivate() function pointer to the __GLimports structure (in glcore.h). That's another ABI issue.
In __MESA_makeCurrent you'll call gc->imports.getReadablePrivate to get the read buffer to pass to XMesaMakeCurrent2(). Before doing this call, you'll have to somehow determine if the imports structure has the new field.
Another approach might be to add a new makeCurrentRead() function to the __GLexports structure (glcore.h) and call that from __glXMakeCurrentRead(), instead of gc->exports.makeCurrent. This would just move the ABI issue from one place to another though.
I'm not sure of what to do about version/ABI checking. The server-side interactions between libglx.a and libGLcore.a is an area that I'm not especially knowledgable of.
Ultimately, a bit of an overhaul of the server side code may be in order. Ideally, libglx.a should be made to understand/use the public interface exported by the DRI drivers (ex. r200_dri.so) and then recast libGLcore.a (the software renderer) to export the same interface. This would finally give us hardware-based indirect rendering. (of course I'm glossing over the details)
-Brian
------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
