GLX and Xgl

[David Reveman]

On Mon, 2005-04-11 at 18:33 +0200, David Reveman wrote:
> 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.

The necessary bits are now in CVS.

To build this you'll need me my previously mentioned patches to
server-side GLX and probably something like the attached patch for
xserver's configure.ac. You might also need to tweak mesa CVS a bit to
make it build. E.g. disable shader objects.

It doesn't work with mesa DRI yet, and some problems with GetProcAddress
when using software mesa. It actually only works OK with nvidia drivers
right now, as far as I know. Only some simple OpenGL applications will
work right now and don't get surprised if some application break the
server completely as client context currently share textures with core
Xgl context and some OpenGL calls that need special treatment are not
yet handled... 

> 
> 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
> 
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
-David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xserver-configure-glx.diff
Type: text/x-patch
Size: 563 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050413/e0d2f139/attachment.bin>