[Mesa3d-dev] GLX and Xgl

[Ian Romanick]

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:
> http://www.cs.umu.se/~c99drn/xgl-glx/
> 
> 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 
tree.

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.

[snip]

> - 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.