AIGLX on Radeon Mobility

Adam Jackson ajax at nwnk.net
Fri Feb 24 13:24:18 PST 2006


On Friday 24 February 2006 12:36, Owen Taylor wrote:
> On Fri, 2006-02-24 at 11:30 -0500, Adam Jackson wrote:
> > I've been staring at the Damage code for a while to figure out how to
> > properly suppress Damages to the moved window during XMoveWindow.  I've
> > failed at it about three times now but hopefully won't fail the fourth. 
> > My most recent effort can be seen in the redhat-xdc2006 branch, which
> > mostly worked but relied on always winning a particular race condition.
>
> The implementation of Damage is hideously hard to understand. My plan of
> attack before was to:
>
>  - Nail down the unclear parts of the spec (most of it...)
>  - Write test cases
>  - Embarrass Keith into fixing the test cases

I don't find it so much hard to understand as just plain _wrong_.  I think 
there's a mistake being made here in trying to do both internal reporting - 
for shadow, sw cursor, automatic compositing, etc. - and external reporting 
using the same mechanism.  It feels like damageext/ shouldn't be implemented 
in terms of miext/damage.

The MoveWindow case is the easiest example, because XMoveWindow is implemented 
internally with the CopyArea GC op; so you don't want to report pixmap damage 
externally because the window's contents haven't changed, but you do want to 
report them internally because you need to use that notification to move 
pixels.  The current scheme of just having an 'internal' flag feels quite 
gross, but I don't really have a better suggestion.

> In the luminocity work, everything was hideously slow initially, and my
> assumption was texture thrashing, but then I wrote texturetop to try and
> confirm that hypothesis (http://fishsoup.net/software/texturetop/ ...
> presumably entirely bitrotted) and it turned out not to be an important
> factor.

I'll take a look at that again, thanks.

> Now with AIGXL, texture updates should be quite a bit cheaper than
> with luminocity, as long as the pixmaps are in system memory, but
> excessive texture updates could still be a pretty big performance
> sink, I'd guess.

I've done sysprof runs showing about 70% of my time being spent in texture 
image pushes, and getting < 30 fps.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060224/87a82fcd/attachment.pgp>


More information about the xorg mailing list