compiz on aiglx

[David Reveman]

On Thu, 2006-03-09 at 10:55 -0800, James Jones wrote:
> 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.

Sounds good to me.

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

Great, I appreciate that. I planned to do the work needed to get compiz
in sync sometime soon but I'll just wait for your patch instead then.

-David