Ian Romanick wrote:
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.
Right. I believe that there also needs to be a readPixmap field.
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).
Right. Then the gc->exports.makeCurrent calls back into the libglx.a side of things to get the drawable datastructures it needs.
I coded it up so that __glXMakeCurrent and friends are just stubs that call a master function called DoMakeCurrent. __glXMakeCurrent looks like:
int __glXMakeCurrent(__GLXclientState *cl, GLbyte *pc)
{
xGLXMakeCurrentReq *req = (xGLXMakeCurrentReq *) pc; return DoMakeCurrent( cl, req->drawable, req->drawable,
req->context, req->oldContextTag );
}__glXMakeCurrentContext and __glXMakeCurrentReadSGI look very similar. All of the real work happens in DoMakeCurrent. I do this because glXMakeCurrent is the same as calling one of the other two functions with the same parameter for drawable and readdrawable. I didn't want to duplicate the code.
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.
Right. This is the same logic I was following. :)
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.
Yes. Not only that, the libglx.a side has to know of the libGLcore.a will want getReadablePrivate to be there. That is, libglx.a has to know if libGLcore.a can support having the drawable and the readable be different.
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 had thought about going that route as well. My main problem is that it adds another nearly complete code path, but doesn't buy us anything.
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.
Ugh. So I guess that makes me the de facto expert? That's scarry! :)
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)
I agree 100%. Here's a question to think about. What are the consequences of breaking this level of binary compatability between XFree 4.4.0 (the next major release) and previous releases? How will this impact the few IHVs that use DRI for their closed-source drivers? If we decide that the risks are, in a relative sense, minor, then I strongly recommend that we start breaking things NOW. :)
For right now, I'm going to get things working by making the ABI changes we've discussed. What I suspect will happen is that I will write the code and probably commit it, *then* we'll resolve our ABI / version checking issues. I'm suggesting this because I think the ABI / version checking issues will take a bit longer to resolve...especially if that means revamping the libglx.a <-> libGLcore.a interface! :)
------------------------------------------------------- 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
