2D slowness in r500 radeon EXA?

[curaga]

After using my new PCIE R500 card with radeon for some weeks I can post some results. Compared to the previous Matrox G450 PCI.

First, image quality is noticably lower. I know this is not related to drivers, but one would expect other companies to have catched up to a 9 year old card way after it's release.

Second, on my CRT I notice "waves" sometimes. This could be from the driver, but also from the weak CRTC of current cards.

3D is of course way faster; the Matrox had opengl 1.2 but for most things it was only barely faster than software rendering. Comparing OpenArena, the Matrox had 640x480 all low @ 80 fps, and now my X1300 Pro has 1024x768 all high @ 110 fps (GL 1.3 in the driver, 2.0 in the HW).

Now the main point. 2D is not "slow" per se, but it is noticably slower than vesa with shadowfb or my old Matrox with it's XAA accel. It takes maybe 2-4 times longer to show windows contents, resize, or open a new tab in Opera for example. It is only noticable because I got used to the old speed; but should it not be faster, not slower?

It has EXA over XAA. It has the bandwith of PCIE 16x vs the bandwith of PCI (133 mib/s -> 4000 mib/s). It has way more ram (32mb -> 256mb). And it's not from the generation that does 2d completely on the 3d engine; it still has a dedicated 2d chip. And the card itself is 7 years newer, has way more power, has better memory (DDR -> DDR2).

Am I out of the line expecting improved 2d performance, not a degradation, from a newer card? Is this something that is caused by the driver, or is this the sad reality?


PS: Radeon devs, don't take this too hard, I do appreciate the tear-free XV that supports 4kx4k video (G450 XV could not play anything over 1024 in width)

[bridgman]

You need a pretty recent X server to take advantage of EXA and get the good 2D performance. Not sure if you need 1.6 or 1.599-something but certainly older X servers don't run so good.

Not sure if this is the problem in your case but something to check.

[curaga]

Running 1.5.1 currently, I'll wait till a formal release of 1.6 is out before wandering there :)

Trying different things from git trunks has the tendency of checking out during times when components do not work together well, or right in the middle of a commit series, etc.

Is the X server the only cause?

[agd5f]

EXA has preformed well for me for a while now. xserver 1.5 should be fine for the most part. 1.6 mainly improves font rendering preformance. Are you using kde 4 by any chance? IIRC kde 4 uses render bits that aren't accelerated with EXA at the moment.

[curaga]

I'm using JWM :)

[oibaf]

I had the same performance problem with old kernels. Make sure you are using at least radeon kernel module 1.29:
~$ dmesg | grep drm
[ 51.116330] [drm] Initialized drm 1.1.0 20060810
[ 51.146754] [drm] Initialized radeon 1.29.0 20080613 on minor 0
[ 51.998257] [drm] Setting GART location based on new memory map
[ 51.999989] [drm] Loading R500 Microcode
[ 52.000118] [drm] Num pipes: 1
[ 52.000132] [drm] writeback test succeeded in 1 usecs

[curaga]

I am using 2.6.28 and the module that comes with (1.29): bash-3.2$ dmesg | grep drm
[drm] Initialized drm 1.1.0 20060810
[drm] Initialized radeon 1.29.0 20080528 on minor 0
[drm] Setting GART location based on new memory map
[drm] Loading R500 Microcode
[drm] Num pipes: 1
[drm] writeback test succeeded in 1 usecs
[drm] Num pipes: 1
[drm] Loading R500 Microcode
[drm] Num pipes: 1
bash-3.2$ uname -a
Linux Valinor 2.6.28-laxy #1 SMP Wed Jan 7 19:23:38 EET 2009 x86_64 Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz GenuineIntel GNU/Linux

[agd5f]

You can trace where the driver is falling back to software by editing radeon_exa.c and changing:
#define RADEON_TRACE_FALL 0
to
#define RADEON_TRACE_FALL 1

then fallbacks will be logged in your xorg log. (note your log could get really big).

[curaga]

Would that be useful? I mean, wouldn't you already know those?

[agd5f]

Would that be useful? I mean, wouldn't you already know those?

EXA works fine for most people (myself included). This would determine what your set of apps is doing to cause a slowdown, assuming the slowdown is fallback related.

[curaga]

OK, just finished. BTW, 6.10.0 would not compile with that defined. Patch for that:diff -Naur xf86-video-ati-6.10.0/src/radeon_exa_render.c xf86-video-ati-6.10.0.fixed/src/radeon_exa_render.c
--- xf86-video-ati-6.10.0/src/radeon_exa_render.c 2009-01-06 21:36:58.000000000 +0200
+++ xf86-video-ati-6.10.0.fixed/src/radeon_exa_render.c 2009-01-21 19:55:52.000000000 +0200
@@ -539,7 +539,7 @@
return FALSE;

if (pDstPicture->format == PICT_a8 && RadeonBlendOp[op].dst_alpha)
- RADEON_FALLBACK("Can't dst alpha blend A8\n");
+ RADEON_FALLBACK(("Can't dst alpha blend A8\n"));

if (pMask)
info->accel_state->has_mask = TRUE;
@@ -847,7 +847,7 @@
return FALSE;

if (pDstPicture->format == PICT_a8 && RadeonBlendOp[op].dst_alpha)
- RADEON_FALLBACK("Can't dst alpha blend A8\n");
+ RADEON_FALLBACK(("Can't dst alpha blend A8\n"));

if (pMask)
info->accel_state->has_mask = TRUE;

[oibaf]

Running 1.5.1 currently, I'll wait till a formal release of 1.6 is out before wandering there :)

Trying different things from git trunks has the tendency of checking out during times when components do not work together well, or right in the middle of a commit series, etc.

Is the X server the only cause?

Note that 1.5.3 includes at least one EXA performance fix:
http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.5-branch&id=f4c33e2e64ce83c29c3bc79853e421247acfea11

With 1.5.3 I got a nice speedup over 1.5.2:
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/280671/comments/6

[curaga]

Well, I wanted to give it a day's use before showing the log. Xorg.0.log was 500kb instead of the usual 25kb.

As far as I can see, the only message from that debug option repeating is:R300CheckCompositeTexture: Unsupported picture format 0x1011000I wonder why it says composite, since JWM does not do compositing. Anyway, in the case I missed something, here's the log uniq'd:
http://rapidshare.com/files/187643512/Xorg.0.log.debug.uniq.html

(no pastebin, for the X copy buffer seems to be too small for the log)

[agd5f]

As far as I can see, the only message from that debug option repeating is:

R300CheckCompositeTexture: Unsupported picture format 0x1011000



That's the a1 (single bit alpha) format, which EXA doesn't accelerate yet.


I wonder why it says composite, since JWM does not do compositing.


The EXA hooks for RENDER acceleration are called composite. Doesn't matter whether you are using a composting manager or not. I'm guessing JWM uses a1 for anti-aliased fonts. kde 4 did something similar and that's why it was slow. They should really be using a8 since both EXA and a lot more hardware can support a8.

[curaga]

Is support for that difficult to implement? Can it happen before 1.6 is out?

[agd5f]

Is support for that difficult to implement? Can it happen before 1.6 is out?

Not likely. Only very recent hw even supports a1 surfaces natively. I suppose you could do some tricks with color expansion on older hw, but core EXA would need a1 support first.

[curaga]

some tricks with color expansion on older hwIs this how XAA handled it?

[agd5f]

XAA is mostly sw. It's faster in some cases because it doesn't even attempt to accelerate most things so there's no migration of data between vram and system ram (which is where you lose).

[panda84]

EXA has preformed well for me for a while now. xserver 1.5 should be fine for the most part. 1.6 mainly improves font rendering preformance. Are you using kde 4 by any chance? IIRC kde 4 uses render bits that aren't accelerated with EXA at the moment.

Mmm... this could be the cause of KDE 4 running sluggishly with radeon with EXA and running amazingly fast with vesa.

[agd5f]

Mmm... this could be the cause of KDE 4 running sluggishly with radeon with EXA and running amazingly fast with vesa.

that's exactly why. kde4 uses a1 surfaces.

[panda84]

[cut] kde 4 did something similar and that's why it was slow. They should really be using a8 since both EXA and a lot more hardware can support a8.
Sorry for the dumb question: did you contact the KDE team? Did you file a bug/wishlist report? What did they reply?

[sundown]

Or maybe it's because you have EXAvsynch on. It might be just me, although I'm keen on doing some benchmarks, but I kind of notice that switching the option on and off makes a difference in resizing windows and switching between windows.

Does anyone have any benchmarks on this already?

[agd5f]

There's no reason to use EXAVSync if you want the fastest performance. It stalls the engine waiting to the vline to avoid tearing for EXA rendering. It has nothing to do with Xv, that is handled separately.

[sundown]

Yeah, but I want tear-free and fast performance :(. Otherwise I need to restart X each time when I switch between them.

[curaga]

I don't have EXAVsync enabled; the only option is "Accelmethod" "EXA".

Am I seeing tear-free display & XV because of not using compositing?

[agd5f]

I don't have EXAVsync enabled; the only option is "Accelmethod" "EXA".

Am I seeing tear-free display & XV because of not using compositing?

The Xv vline stuff is handled separately from EXA. Same process though.