GLX and Xgl

[David Reveman]

I've got GLX and indirect rendering working with Xgl. It's accelerated
and works fine with Composite. There's of course a lot more work to be
done but I don't plan on going much further until we're using
framebuffer objects in Xgl as it would mean adding code that will be
thrown away later.

The glitz and Xgl code needed to get this working is in pretty good
shape and it should land in CVS in a few days.

But I had to do some pretty drastic changes to server side GLX code and
I'm not sure that my current solutions are the best way to go. Here's
what I've done:

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?


I had to add a 8A8R8G8B pixel format to XMesa for ARGB visuals to work
properly. This patch should do that:
http://www.cs.umu.se/~c99drn/xgl-glx/Mesa-PF_8A8R8G8B.diff


With all the above changes in place I can run simple OpenGL applications
accelerated while using a compositing manager, and by changing a few
lines in the applications I can get them to use ARGB visuals as well.


The following is not working:
- Context Sharing (all contexts are currently shared)
- Drawing to front buffer
- CopyPixels 

All contexts need to be shared inside Xgl so we're going to have to keep
hash tables in Xgl to deal with GLX contexts.

Getting front buffer drawing to work is a bit harder. We need to report
damage and do pixel ownership test. Using the current scissor box when
reporting damage is probably good enough but I don't have good solution
for pixel ownership test. I guess we're going to have to do multiple
drawing operations with different scissor boxes but that will make
display lists much harder to handle...

CopyPixels between different buffers is not working right now, but when
we're using framebuffer objects this will work just fine.


My current plans for GLX support in Xgl and for Xgl in general are as
follows:

- Textures are used for pixmaps and framebuffer objects for drawing to
them. No GL_EXT_framebuffer_object support, no accelerated offscreen
drawing.

- Windows that are not redirected to pixmaps will when attached to a GLX
context use the back buffer, stencil bits and depth bits provided by the
real framebuffer. For windows that are redirected we'll allocate
back/depth/stencil buffers dynamically as needed.

- The compositing manager will most likely be using indirect GLX for
drawing the desktop. A double buffered GL visual can be used to
efficiently draw the desktop even when GL_EXT_framebuffer_object isn't
present and buffer flips can be used when redrawing the whole screen.

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

This is just what I believe is the best way to go, it's not in any way
set in stone, it's all open for discussion. Comments and suggestions are
of course much appreciated.

-David