GLX and Xgl

[David Reveman]

On Tue, 2005-04-12 at 17:49 +0200, Matthias Hopf wrote: 
> On Apr 11, 05 18:33:32 +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
> 
> Great job, David!

thanks :) 
> 
> > 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.
> 
> Just some thoughts of me, if I get this correctly:
> 
> - Only indirect rendering is possible at the moment, and this isn't
>   trivially changeable.

Correct.

> 
> - You are only able to render redirected OpenGL apps accelerated, when
>   the driver has PBuffer support, because you need a rendering context
>   for the application (if you do not want to re-invent the wheel
>   everywhere and do state tracking yourself).
>   Do you need PBuffers for non-redirected windows as well?

The back buffer is currently allocated in the same way as pixmaps and
Xgl is currently using the *real* back buffer for pixmaps so you might
be able to run non-redirected windows accelerated without pbuffers. This
stupid use of the *real* back buffer for pixmaps is only there so that
we can test and get these things (XRender, Composite...) running before
we have framebuffer object support. Once we can start to use framebuffer
objects I'll change so that the *real* back buffer is used as back
buffer for non-redirected windows.

> 
> - As soon as framebuffer objects exist and should be used for off-screen
>   rendering contexts, we would need something like ARB_render_target,
>   otherwise we couldn't provide the applications with a context to
>   render into. Or we have to intercept all BindRenderbufferEXT() etc.
>   calls from the application.

We'll have to intercept BindRenderbuffer, BindFramebuffer... but I think
we can get that working without to much trouble. I don't see how
ARB_render_target could be of help here... is that extension still
considered? 

> 
> So are you doing something differently when nothing is redirected?
> What kind of context do OpenGL applications get when creating their
> rendering context, where do they actually render into? You current root
> context with scissor tests applied, or is it handled just like the
> redirected case with PBuffers?

Clients always get their own contexts. Buffers are allocated as pixmaps
but that will change, just as I mentioned above. 

> 
> 
> What do we need for direct rendering in the context of Xgl, and more
> importantly, what do we actually want?
> 
> I can see three scenarios - with transitions possible:
> 
> - Non-redirected (no composite manager), windowed applications
> - Redirected, windowed applications
> - Full-screen applications
> 
> The reason I split here for windowed / full-screen applications is that
> full-screen applications *could* be handled differently, and as these
> are typically games lag must be avoided more strictly than with the
> other cases. I'm currently not sure if it save to assume that
> full-screen apps would never interfere with a composite manager, but I
> have the feeling they shouldn't.
> 
> Do we have a possibility to handle all three scenarios the same way?
> Currently I doubt, because composite managers inherently add lag.
> Is this something to be discussed outside Xgl because it is composite
> related? Could very well be.

Yes, that's probably a Composite thing and not really specific to Xgl.

> 
> 
> So how can we make - in the long term - make direct rendering with Xgl
> possible? So far I think we basically need
> 
> - EXT_framebuffer_object for rendering X requests into a texture in
>   the server
> - some extension yet to be specified, which allows sharing of textures
>   between processes (Xgl and application)

Yes.

> - ARB_render_texture to create a context on the application side that
>   renders into a texture

So far I've only thought of using GLX_ARB_render_texture for indirect
rendering. Don't know if it's a good idea to use it for direct rendering
as well but maybe that's possible. Either way, that's all transparent to
the client so it wouldn't be to too bad if it turns out we need
something else, right? 

> Then there's still the issue that the libGL on the application side
> would have to create a context that renders into a texture, without the
> application actually noticing it. This is currently what scares me most.
> 
> One alternative would be another extension that would allow the
> transport of one context to another process, so the context for
> rendering into a texture could be created on the Xgl side, and the
> context could then be transferd to the application side. This sounds
> scary as well. I doubt that an extension for shared contextes would work
> without patching the application side libGL, either.
> 
> Any other ideas? What else did I forget?
> 
> For the non-redirected case, an application could render into its own
> OpenGL context, but this would make occlusion, window stacking, etc.
> a nightmare.
> 
> 
> > The following is not working:
> > - Context Sharing (all contexts are currently shared)
> 
> That is, textures are currently only working correctly, if all
> applications use GenTextures(), right?

Exactly.

> 
> > - Drawing to front buffer
> 
> In the redirected case as well? 
> Does this not work at all, or is it just that glFlush() does not call
> the update routine in order to copy drawing results to the screen?

Currently not at all, but it wouldn't be too hard to get this working.

> 
> > 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...
> 
> What happens if the application wants to use the scissor test on its own?
> For indirect rendering we could always interprete the protocol ourself
> (Ugh) and adapt the test to our needs, but for direct rendering I have
> no clue.

I'm intersecting the client scissor box with window bounds right now.
Means trouble when display lists are used but I think that can be solved
for indirect rendering by splitting up display lists on the server-side.
Don't know about direct rendering. When we're drawing to framebuffer
objects we don't have to do this.

> 
> 
> > - Textures are used for pixmaps and framebuffer objects for drawing to
> > them. No GL_EXT_framebuffer_object support, no accelerated offscreen
> > drawing.
> 
> Agreed. This sounds sensible.
> 
> (the rest as well)
> 
> > - 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.
> 
> Right, for the compositing manager only being able to use indirect
> rendering shouldn't be a problem. At least right now I cannot imagine a
> usefull one that needs so much geometry that it is severely hindered.
> 
> 
> Thanks
> 
> Matthias
> 

-David