GLX and Xgl

[Matthias Hopf]

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!

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

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

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

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?


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.


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)
- ARB_render_texture to create a context on the application side that
  renders into a texture

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?

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

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

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

-- 
Matthias Hopf <mhopf at suse.de>       __        __   __
Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat at mshopf.de
Phone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de