radeon EXA performance questions

[Owen Taylor]

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. (I'm not sure if there is any optimization of
this on systems with ARGB pixmaps ... most GTK+ themes draw an alpha
channel correctly in that case.)

> > 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.

- Owen