radeon EXA performance questions

Owen Taylor otaylor at redhat.com
Mon Aug 4 09:55:32 PDT 2008


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

That CPU time is spent here doesn't necessarily mean that this the
actual bottleneck... GetImage needs to wait for the GPU to become
idle, and that involves a busy-wait currently. (At least with the DRM,
and probably otherwise.)

When I've seen GetImage taking most of the CPU, that's typically meant
that drawing in general is GPU bound, so the CPU gets ahead of the
GPU and blocks in GetImage. 

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.

- Owen





More information about the xorg mailing list