compiz on aiglx

[James Jones]

On Thursday 09 March 2006 06:53 am, David Reveman wrote:
> On Mon, 2006-03-06 at 14:01 -0500, Kristian Høgsberg wrote:
> > Hey,
> >
> > With a bit of hacking, I managed to get compiz (and glxcompmgr)
> > running on aiglx.  I'm running it on my i830 laptop, and the
> > performance is actually quite impressive.
> >
> > Most of the aiglx fixes were just bug fixes or missing minor
> > features and have been committed to the accel_indirect_branch. 
> > A couple of fixes are less committable and I've put them here:
> >
> >    http://freedesktop.org/~krh/compiz-on-aiglx
> >
> > The aiglx-gl-include-inferiors.patch make the DRI driver draw
> > over child windows, and the patch is really simple.   The
> > question is what kind of protocol do we need to enable this...
> > an FBConfig attribute might work, or maybe the question is, why
> > does redirected window affect output at all again? 
> > Furthermore, for compiz to work, the root visual must be double
> > buffered, which really just depends on how the DDX driver
> > initializes the visual configs.  The i830 sets it up correctly,
> > but the radeon driver needs something like this:
> >
> >   
> > http://people.freedesktop.org/~ajax/radeon-prefer-db-visuals-1.
> >patch
> >
> > to make sure the root window gets a double buffer visual.

We plan to provide an X option in our driver that turns off clipping 
of GLX drawing to the root window.  This will be a workaround for 
users who wish to experiment with GLX-based composite managers 
until X servers and composite managers using the composite overlay 
window are available.

> > The aiglx-tfp-damage.patch adds damage tracking to the naive
> > GLX_EXT_tfp implementation in aiglx.  It sometimes misses
> > damage events it seems and it really should track damage per
> > texture object so it's not committed yet.
> >
> > The compiz-aiglx-changes.patch makes a couple of changes to
> > compiz to make it work on aiglx: first, as I remember from
> > xdevconf, the consensus around GLX_EXT_tfp semantics was that
> > it binds a copy (conceptually) of the pixmap as the texture. 
> > This is what aiglx implements, but it looks like Xgl sematics
> > is that the texture and pixmap share the same memory and only
> > binds and releases the pixmap on pixmap creation and
> > destruction time.  The patch changes compiz to bind and release
> > whenever the texture is used, which is why the damage tracking
> > tfp patch above is essential for decent performance.  I'm not
> > sure the copy semantics makes sense, though, but I'll write
> > another email about that.  Another change in the patch is
> > support for the GLX_Y_INVERTED_EXT atrribute on a GLX drawable.
> >  Xgl binds the pixmap y-inverted, aiglx doesn't so compiz needs
> > to know how to handle this.  Of course, this should be an
> > FBConfig attribute not a drawable attribute.
>
> Yes, we agreed that GLX_EXT_tfp semantics should be that it binds
> a copy and it makes sense for being able to completely avoid
> tearing. I haven't updated compiz and Xgl for that yet. Textures
> and pixmaps will continue to share the same memory in Xgl so to
> get copy-on-bind semantics I have to be able to lock a drawable
> so that no other client can write to it. I don't know how hard
> that will be but updating compiz to bind before every draw could
> be done right without breaking anything.

The copy-on-write wording was thrown around a lot at the dev 
conference, but I don't think its what was generally desired.  This 
would require one of the following:

1) block all drawing to a drawable while it is bound as a texture.  
This is just can not be done without extensive changes in the X 
server.  From what I can see, it would require determining which 
drawables are affected by incoming operations, then backing out of 
the operation, putting that client to sleep until the drawable was 
unbound from the texture, then waking up the client and resuming 
the operation.

2) Doing an implicit copy if the drawable is going to be damaged 
while it is bound to a texture, then updating the texture to point 
to the copy.  This might be slightly easier than the above, but it 
still becomes very involved with direct rendering clients.  Also, 
it would mostly eliminate the benefit binding drawables directly to 
textures.  If we need to copy, it removes all the performance 
benefit.

I interpreted the discussion we had this way:

The drawable can not be rendered to, by X, OpenGL, or any other 
direct rendering client, while it is bound to a texture.  It is the 
applications job to enforce this.  This can be done with server 
grabs.  If the application obeys this rule, the BindTexture 
operation will indeed act as if it were a CopyTexSubImage operation 
in this case.

If the application does not want to grab, all bets are off.  The 
contents of the texture are undefined if it is rendered to while 
bound.  That said, I suspect this will still work on most 
implementations, but there may be tearing.  We have all seen it 
work on Xgl, I'm ensuring it works in our driver, and it sounds 
like it will work in aiglx since you are doing damage tracking to 
update the texture.

I have a EXT_tfp spec update outstanding that addresses this and a 
few other minor issues with the current version.  I'll try to clean 
this up and send it out later today.

I'm also working on a patch that will bring compiz in sync with the 
extension as defined in the specification, which should build on 
your compiz patch Kristian.

Thanks,
-James Jones

> GLX_Y_INVERTED_EXT is y-inverted in respect to GL. So if aiglx is
> different than xgl, GLX_Y_INVERTED_EXT should be set to TRUE in
> aiglx.
>
> -David
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg