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