GLX and Xgl

[David Reveman]

On Wed, 2005-04-13 at 20:37 +0200, Matthias Hopf wrote: 
> This is getting a longer post, again...
> 
> On Apr 12, 05 21:12:48 +0200, David Reveman wrote:
> > On Tue, 2005-04-12 at 17:49 +0200, Matthias Hopf wrote: 
> > > - 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
> 
> Again, with scissor test, I imagine?

Yes. 

> > 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.
> 
> Then we can actually intercept glXSwapBuffers() and account for
> overlapping windows etc. pp. I guess this will make things much easier.

We're always intercepting glXSwapBuffers, there's no way not to, as it's
window system dependent. I'm currently just doing a CopyArea from the
back buffer pixmap to the drawable, that way I get damage and composite
working OK. This CopyArea is currently done from Xgl's core context,
which mean that a context switch occurs at every buffer swap. This makes
high frame rate clients like glxgears loose some performance. Not that I
see it as a big problem that clients that could run at 4000 FPS only run
at 3000 FPS... but we might want do the swap from the client context in
the future, especially when the window isn't redirected and it's clip
region covers all of the screen as we can then use the native
SwapBuffers.

> 
> > > - 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
> 
> I'll guess so.
> 
> > ARB_render_target could be of help here... is that extension still
> > considered? 
> 
> Don't think so.  I think I missunderstood something WRT this extension -
> you explained that to another guy already, I guess I see a bit clearer
> now.

Are we mixing up extension names here? There's no ARB_render_target as
far as I know. I think there is or was a EXT_render_target with similar
functionality as EXT_framebuffer_object, I thought you were talking
about that one. I guess you just meant GLX_ARB_render_texture.

> 
> > > 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.
> 
> Let's look at an application that is just about to create a new context
> / bind the context to a drawable:
> (glXCreateNewContext/glXCreateContext/glXMakeContextCurrent/glXMakeCurrent)
> 
> For indirect rendering we can just create a context, BindRenderbuffer()
> the current Pixmap texture to it, and after that(!) return the context
> id to the application. Calls to BindRenderbuffer() etc. have to be
> intercepted, so that binding to 0 actually binds to the Pixmap texture
> again.

Yes, checkout the current CVS code to see how this is currently done. No
framebuffer object support for server-side GLX yet so we don't have to
worry BindRenderbuffer right now. 

> 
> For direct rendering things are getting more complicated. The libgl has
> to be changed so that it supports a mechanism to let the application
> create a direct rendering context, that renders not into the framebuffer
> but into the Pixmap texture. For a regular XWindow. This cannot be done
> without code change in the library.
> 
> It doesn't matter, because we have to have additional functionality
> (extension) anyway: we need to have a way of sharing a texture with
> another process id.
> 
> As all of this cannot be done in a backwards-compatible manner,
> applications linked to old / unextended versions of the library can only
> be supported using indirect rendering. Not really a problem (who links
> statically against libgl anyway).

Being able to get direct rendering working in a backwards-compatible
manner never crossed my mind. 

> 
> So I currently see the need for two extensions:
> 
> - Share a texture with another process, that is with another address
>   space (GL_shared_texture).
> 
>   For security reasons and ease of implementation this would have to be
>   twofold: the Xserver would have to export the texture, creating an
>   unambiguous ID, transfer this ID to the client, then the client would
>   have to import the texture using this ID. We would have to think about
>   whether we need locking mechanisms here as well, at least for
>   format/size changes.
> 
> - Identify displays that may correspond with shared textures and change
>   the way contexts are created and bound (GLX_shared_texture_context).
> 
>   The client would have to identify displays with windows associated to
>   off-screen buffers. If (and only if) a direct rendering context is to
>   be created to one of these windows, it should contact the Xserver and
>   ask him for an texture export ID, then bind this texture for its
>   rendering context. So this extension is tightly coupled with
>   GL_shared_texture.
>   On the client side this could actually be coupled with framebuffer
>   objects.
>   
> I would write proposals as soon as we agree on what we actually need,
> but I think we are a bit too early in the discussion process for that.

Yes, and I think we're also too early in the development faze. We should
probably get indirect rendering fully working and Xegl at least close to
working before we start writing proposals for this.
> 
> Right now I have no good solution what should happen with OpenGL
> applications when a composite manager redirects / unredirects windows. I
> guess the easiest way would be to always render into offscreen buffers,
> whether a window is redirected or not. For indirect rendering this
> shouldn't be problematic, as the Xserver is in control of where to
> render to.
> 
> > > - 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? 
> 
> Very right. The only possibility for using this extension for creating
> the context would be to patch the system libGL as well. I don't like
> this idea, we would have to have special cases for NVidia/ATI here as
> well.
> 
> 
> > > That is, textures are currently only working correctly, if all
> > > applications use GenTextures(), right?
> > Exactly.
> 
> So most of mine won't :-]  Was lazy until now...
> 
> > > > 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.
> 
> So you already implemented the (Ugh) case - very impressive :)
> 
> > 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.
> 
> Oh, right, now I understand why display lists could be a problem.
> Luckily, typically no scissor test changes are incorporated into display
> lists. I'm not saying that we shouldn't care ;)

And serious OpenGL applications will probably be using VBOs and not be
display list so some minor performance issues with display lists isn't
that bad. 

> 
> > Don't know about direct rendering. When we're drawing to framebuffer
> > objects we don't have to do this.
> 
> Right. For double buffered applications this should be easy to implement
> (copy to screen on glXSwapBuffers()), for single buffered applications
> we could emulate single buffer with a copy to screen on glXFlush()...

Yes, we're probably going have to do something like that for direct
rendering. 

-David