radeon EXA performance questions

[Michel Dänzer]

On Tue, 2008-08-05 at 10:30 -0400, Owen Taylor wrote:
> On Tue, 2008-08-05 at 08:41 +0200, Michel Dänzer wrote:
> > On Mon, 2008-08-04 at 12:55 -0400, Owen Taylor wrote:
> > > On Mon, 2008-08-04 at 11:36 +0200, Michel Dänzer wrote:
> > > > On Fri, 2008-08-01 at 12:40 +0200, Simon Thum wrote:
> > > > > Michel Dänzer wrote:
> > > > > > 
> > > > > >> complex app takes 1/3 sec or even more). Obviously some ops are still 
> > > > > >> suboptimal. Is there interest in oprofile data?
> > > > > > 
> > > > > > Sure, though I prefer sysprof (or at least output from opreport -c as
> > > > > > well as opreport -l).
> > > > > Said, done. I didn't experience the dropout, but this profile should 
> > > > > capture what I mean. I switched eclipse, firefox and thunderbird, 
> > > > > scrolling a lot in the latter over this lovely mailing list. This is a 
> > > > > particular slow thing in EXA, roughly comparable to unpatched XAA with 
> > > > > offscreen pixmaps.
> > > > 
> > > > Note that every profile should be limited to a single isolated action as
> > > > much as possible in order to maximize its usefulness.
> > > > 
> > > > This profile shows 40% of the cycles spent copying data from video RAM
> > > > to system RAM for GetImage (Not sure what that's used for in the actions
> > > > described above...).
> > > 
> > > Firefox uses GetImage when drawing "natively themed" widgets in a web
> > > page, like buttons or input boxes. (It draws them with GTK+ to a pixmap,
> > > then gets the image from there and composites it into a page.)
> > 
> > Hmm, couldn't it render from the pixmap directly?
> 
> Firefox needs an image of the native widget with an alpha channel, which
> the 1998-vintage GTK+ theme API doesn't provide. So, in cartoon, what it
> does is:
> 
>  - Draw the widget on a white background
>  - Draw the widget on a black background
> 
> Then fetch the two images back into client memory and compute an alpha
> channel by comparing them.

Oh right, the Qt4 GTK+ style does the same thing... how hideous, and
OTOH surprising how usable the latter is given this. :)


> > > I can't find the actual profile in the list archives, so I'm not sure if
> > > the CPU time is waiting for the GPU to go idle, or it's actually
> > > spent in the copying itself, which would indicate a different sort of
> > > problem ... perhaps cairo is using extensive software fallbacks for some
> > > reason.
> > 
> > Most of it was in libc, i.e. the memcpy for copying data from video RAM
> > to system RAM for GetImage. Enabling the DRI and AccelDFS should most
> > likely reduce that somewhat, but of course you're right that this may
> > not necessarily improve things otherwise. We'll have to see. :)
> 
> As noted in my other mail, I think my "native widget rendering"
> hypothesis was likely wrong given the Firefox version. So, not really
> sure what was going on... GetImage for large areas of the screen should
> be pretty rare.

Right, though if GetImage is called often, the areas don't necessarily
need to be very large for it to appear on the radar... CPU reads from
video RAM are on the order of 10 MB/s with AGP.


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer