Bug 26225

Could it be radeon does call pixman_rasterize_edges on an memory-area which is not cached? pixman_rasterize_edges does a lot of read-modify-write, so that could probably the source of some performance problems. (at least it was in the intel-driver when they switched to GEM).

radeon doesn't call any pixman stuff directly.  It just provides EXA hooks and the core EXA code in the xserver does the rest.  I suspect you are hitting a software fallback for a specific operation and due to the migration of data from then back to vram you are seeing the slow down.  With accel disabled, the driver uses shadowfb which keeps the framebuffer in system ram so software fallbacks do not require migration across the bus.

But beeing hurt by migration, sysprof would not report all the time spent inside  pixman_rasterize_edges, right?

(In reply to comment #3)
> But beeing hurt by migration, sysprof would not report all the time spent
> inside  pixman_rasterize_edges, right?

The problem is likely that pixman_rasterize_edges ends up operating on VRAM directly. It should be better as of xserver 1.7.x thanks to a new EXA feature called 'mixed pixmaps' which should result in pixman_rasterize_edges operating on system memory.

Ok, running from the Ubuntu Lucid LiveCD I get 7 fps with EXA.

ii  xserver-xorg-core                    2:1.7.3.902-1ubuntu9                           Xorg X server - core server
ii  xserver-xorg-video-radeon            1:6.12.99+git20091125.0061c4db-0ubuntu2        X.Org X server -- ATI Radeon display driver
ii  libdrm-radeon1                       2.4.17-0ubuntu2                                Userspace interface to radeon-specific kerne

Some xorg log messages
(II) RADEON(0): EXA: Driver will allow EXA pixmaps in VRAM
(II) RADEON(0): [DRI2] Setup complete
(II) RADEON(0): Setting EXA maxPitchBytes
(II) EXA(0): Driver allocated offscreen pixmaps
(II) EXA(0): Driver registered support for the following operations:
(II)         Solid
(II)         Copy
(II)         Composite (RENDER acceleration)
(II)         UploadToScreen
(II)         DownloadFromScreen
(II) RADEON(0): Acceleration enabled
(==) RADEON(0): DPMS enabled
(==) RADEON(0): Silken mouse enabled
(II) RADEON(0): Set up textured video
(II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled message.

(II) [KMS] Kernel modesetting enabled.
(II) RADEON(0): KMS Color Tiling: disabled

OK, given that in your original report you mentioned you were using "Latest drm-radeon-testing kernel as of a few days back with KMS", I think what we need to properly compare your setup in comment #5 with that in your original report (thus testing the change described in comment #4), is for you to boot Ubuntu 10.04 Lucid Lynx from the Live CD (or install it) and then upgrade the kernel to 2.6.33-rc8 (or later) from http://kernel.ubuntu.com/~kernel-ppa/mainline/

With vanilla Lucid from today I get 10 fps now!
(Btw Firefox version doesn't seem to matter, tried with 3.5, 3.6 and 3.7)

> With vanilla Lucid from today I get 10 fps now!

OK, we're getting somewhere, albeit slowly.  Are you able to try that setup with the 2.6.33 kernel?

> (Btw Firefox version doesn't seem to matter, tried with 3.5, 3.6 and 3.7)

Interesting - I'm running Lucid 10.04 (32 bit) with Mesa updated to the latest Lucid package, I'm not using KMS. On my old R350 I get a nice speed increase of approximately 11% on that site when upgrading from Firefox 3.5.7 to Firefox 3.6.

Can you try xf86-video-ati git master?  Specifically this commit:
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=488c9fd8300505cc6c0c2f8f0f00849f27cc5d63

I just tried, on my radeon mobility X1600 at least, scrooling in firefox is still excruciatingly slow.

This seems more related to the new DRM in kernel 2.6.34RC1.  Running latest xorg-edgers packages, but xf86-video-radeon compiled from git. 

Short answer: doesn't change anything with xserver 1.6.5
Long answer: I'm preparing a huge testmatrix! :-)

(PS scrolling in firefox is basically fast in every configuration for me, 2.6.34RC1 seems like a nice upgrade with slightly better scores)

The patch only affects r6xx/r7xx chips.

Created attachment 34085 [details]
I spent way too much time with this :-)

Yey, with xserver 1.7 and firefox 3.7a3 that patch improves performance ~100% (from 26/s to 48/s). Calling this fixed!