radeon EXA & fallbacks
eta at lclark.edu
Thu Sep 22 01:19:06 PDT 2005
On Thu, 2005-09-22 at 17:51 +1000, Benjamin Herrenschmidt wrote:
> I find radeon EXA fairly slow for a bunch of things, like scrolling the
> list in evolution or even ls -lR / in gnome-terminal. I did a bit of
> oprofile and I'm spending a lot of time in memcpy,
> fbCompositeSolidMask_nx8888x8888C and fbBlt. I don't have proper
> backtraces yet though.
> I did some quick traces of the driver and it seems I'm getting a lot of
> fallbacks due to:
> R200CheckComposite: Component alpha not supported with source alpha
> The typical kind of operations are:
> Composite fallback: op Over,
> src 0x106e0370:m fmt ARGB8888 (1x1 R),
> mask 0x1068abe8:s fmt ARGB8888 (259x10),
> dst 0x10ba3ea0:s fmt xRGB8888 (512x512),
> EXA fallback at ExaCheckComposite: from picts 0x10685f20/0x106e3590 to pict 0x10685588
> (btw. Eric, I added xRGB8888 to your list of pixmap type "names").
> This is with gtk 2.8.3-1 from debian, xft2 2.1.7-1, pango 1.10.0-2,
> using an aa font in both case (Bitstream Vera Sans Mono 7.5 for the
> ls -lR test and Arial from msfonts for evolution).
> My lack of knowledge of 3D engines hitting hard here, I'll let you
> guys have fun figuring it out :)
Yep, you've got subpixel antialiasing on your fonts, right? This is
really hard to accelerate. Basically you've got *two* ARGB8888 values
for source that need to get passed in to the blending along with the
dest, which the card's BLEND_CNTL-type blending doesn't support.
I'm pretty sure we could accelerate it in a single pass on Radeons using
a temporary pixmap containing a copy of the destination as a source
texture, but this is going to require help from EXA to do it cleanly.
And I haven't verified, so I'm waving my hands and saying "the texture
blenders are enough for the OP blending, right?"
The other proposal has been to do this in four passes (one per channel),
with no temporary, using planemasks. I'm highly dubious of this, and I
haven't heard it explained exactly how this will be done without four
uploads, as well. Or two passes on Radeon, thanks to the versatility of
the texture formats and byte swapping, but that was really
Eric Anholt eta at lclark.edu
http://people.freebsd.org/~anholt/ anholt at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 187 bytes
Desc: This is a digitally signed message part
More information about the xorg