AIGLX on Radeon Mobility

[Owen Taylor]

On Fri, 2006-02-24 at 11:30 -0500, Adam Jackson wrote:
> On Thursday 23 February 2006 13:31, Owen Taylor wrote:
> > But updating textures should be irrelevant when dragging windows around,
> > right?
> 
> You'd think that.  The problem is we don't update textures only when the 
> windows they're bound to get updated, but many other times too.
> 
> > Could damage bugs be causing excessive texture updates? luminocity
> > needed some hacks to the X server to work around excessive exposes being
> > generated by DAMAGE.
> 
> 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

But I never got beyond part of the first step...
 
> But then the other problem is you still have to redraw the exposed areas, and 
> if those textures got kicked out of vram between the last time they were 
> drawn and now, you lose.  This happens quite frequently because our drivers 
> suck and have little to no concept of memory management, a refrain that 
> should sound pretty familiar right now.  So if it sounds like I'm punting 
> until that work approaches generally usable, well, I am.
> 
> And at least in the metacity case, we really do redraw the entire scene, which 
> means we have to shove a texture for _every_ visible pixmap into VRAM before 
> glXSwapBuffers.  compiz is slightly smarter but relies on having accelerated 
> glCopyPixels, which is probably a win overall.

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.

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.

Regards,
						Owen