compiz on aiglx
davidr at novell.com
Fri Mar 10 04:49:26 PST 2006
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
> 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.
More information about the xorg