[Mesa3d-dev] GLX and Xgl

[David Reveman]

On Mon, 2005-04-11 at 11:52 -0700, Ian Romanick wrote: 
> 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.

Good, just what I need.

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

Pretty much exactly what I'm doing in Xgl right now. 

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

It would be nice for me if we can get something like that into CVS soon.
Even if it's just some temporary solution that we'll use until you're
finished with the real thing that's fine with me.

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

Sure.

Using the Composite extension and a GL based compositing manager for
drawing the desktop is what we want. What a GL based compositing manager
needs to be able to draw the desktop is top level windows as textures.
Xgl already stores top level windows as textures so this can be very
efficient with Xgl. What we need is some way for the compositing manager
to bind an X drawable to a texture id in it's GL context. So we need a
new window system dependent GL extensions for this. Accidentally this
happens to be almost exactly what GLX_ARB_render_texture is supposed to
do, maybe we can just use that extension now that we found a use for it.

I'm going to implement this in Xgl and we can then see what we want to
do. New extension or use GLX_ARB_render_texture, doesn't really matter
for me. But it's going to supply the functionality of
GLX_ARB_render_texture either way.

-David