[Mesa3d-dev] GLX and Xgl
idr at us.ibm.com
Mon Apr 11 11:52:46 PDT 2005
David Reveman wrote:
> 1. Made glcore use MGL namespace. This allows me to always have software
> mesa available and this is currently necessary as there might not be
> enough resources to use the *real* GL stack with Composite. It might not
> be necessary when we're using framebuffer objects but I still think it's
> a good idea. This works fine when running Xgl on top of nvidia's GL
> stack or software mesa, but I haven't been able to get it running on top
> of mesa/DRI yet.
> 2. Made all GL calls in server side GLX go through another dispatch
> table. Allows me to switch between software mesa and *real* GL stack as
> I like. This is also necessary as extension function pointers might be
> different between contexts and we need to wrap some GL calls. e.g.
> glViewport needs an offset.
> Both these changes are available as patches from here:
> xserver-mesa.diff also include some changes required to get xserver
> compiling with mesa CVS and a few lines to support ARGB visuals.
> xserver-glx.diff modifies files that seem to be auto generated but I
> didn't find the source to that so I just made the changes directly. Most
> of these changes were done by running a regexp on all files in
> xserver/GL/glx directory.
> Does this seem like reasonable changes?
So, it turns out that I'm currently working on some similar stuff.
Basically, I'm competely ripping up the interface between libglx ("the
loader" hereafter) and libGLcore ("the driver" hereafter). The final
goal is to get libglx to load a DRI driver. A big part of this is
replacing the static dispatch functions (e.g., glVertex3fv) in libGLcore
with a dispatch table, like is used on the client-side.
The net result is that *all* the gl* functions are *gone* from the
driver. The driver's bindContext function populates a dispatch table
and calls _glapi_set_dispatch. Anything in the loader that wants to
call glVertex3fv just does some flavor of 'dispatch->Vertex3fv(v)'.
Another big part has been to replace all the "auto generated" code with
new autogenerated code. The replacement code *will* have scripts
available, and uses the gl_API.xml "stuff" in src/mesa/glapi in the Mesa
I haven't committed (or released as patches) any of this yet because
it's pretty big, and I don't see a clear way to cherry-pick any parts of
it out. Pretty much all of my changes end up breaking GLX for Darwin
and cygwin. After looking at your xserver-glx.diff patch, I'll see if I
can pull out my dispatch table changes.
> - All visuals will be GL visuals and by reviving GL_ARB_render_texture
> and implementing it in Xgl we'll make it possible for GL applications to
> bind a X drawable to a texture id. This is what a GL compositing manager
> will do for all top level windows.
Can you elaborate on this more? The reason I'm asking is that, with the
advent of EXT_framebuffer_object, there is almost no chance that there
will ever be a GLX_ARB_render_texture extension. Even before
EXT_framebuffer_object there were a few efforts to start a working group
for that extension, and there just wasn't enough interest to get it going.
More information about the dri-egl