Just for the record, I can confirm this issue here as well. DRI2 barely runs etracer on my Radeon 9000 mobility, with the dri1 code it runs at 200+ fps. Similar results on my r500 card.

this is likely a dup of bug 26599.  The slow down is at least partially caused by the anti-tearing code used for buffer swaps.

This problem still exists, UMS(as far as 3D is still working with it) is much faster than KMS. Unfortunately the only app that's still working with UMS in Mesa 7.11 is glxgears.

On my r250 GPU glxgeares runs at 2600 fps with UMS, 1070 with KMS(default Window size). At 1400x1050 the numbers are 370 fps(UMS) and 60 fps(KMS).

I don't think vsync causes the issue, disabling it seems to work fine, at least for windowed apps.

etracer is still a lot slower with KMS than it used to be. At 1400x1050 and otherwise default settings it runs at 15-20 fps. With an ancient Mesa version I tested today(6.4.2) it runs at a pretty okish 60 fps at the same settings.

The problem seems to be on the GPU side. Whenever the problem occurs the CPU is idle and the GPU working, and increasing the rendering resolution makes the problem worse. The unfortunate situation this creates is that the 6 years old Mesa on my old hard drive vastly outperforms Mesa 7.11 in many rendering situations.

I could not spot any CPU side problems, but the GPU slowness makes it hard to test. My unscientific guess is that in setups where the KMS GPU slowness doesn't matter Mesa 7.11 is about 50% faster than Mesa 6.4.2. (etracer with a tiny resolution, long view range and lots of objects)

I'll test r300 on a Radeon X1600 GPU over the weekend. This GPU/driver combo is pretty slow as well, but I'm not sure if r300 still supports UMS.

(In reply to comment #3)
> This problem still exists,
I forgot to add the usual software version info:

Kernel: 3.0.4-gentoo
Xorg: X.Org X Server 1.10.2
DDX: xf86-video-ati-6.14.2
Mesa: Mesa 7.11. (Also tried mesa git, revision db3a7c366b5)

This is because output is maxed at screen refreshing and won't go over 60fps

That does not explain the 15-20 fps he sees with etracer.

(In reply to comment #4)
> (In reply to comment #3)
> > This problem still exists,
> I forgot to add the usual software version info:
> 
> Kernel: 3.0.4-gentoo
> Xorg: X.Org X Server 1.10.2
> DDX: xf86-video-ati-6.14.2
> Mesa: Mesa 7.11. (Also tried mesa git, revision db3a7c366b5)

Can you also post the output of dmesg and glxinfo, as well as your Xorg.log.

UMS supported Colortiling and hyperZ on r1xx/r2xx asics and a few other features that haven't been implemented with KMS yet.  The information is available if someone wants to add support to KMS.  KMS also defaults to vsynced 3D.  r3xx and newer asics should be faster with KMS.

I tested this on r300(g) with a Radeon X1600, and the results were inconclusive. UMS only ran glxgears resonably, and in fullscreen it always forced vsync on. r300g outperformed r300 in real apps(e.g. etracer).

However, the X1600 with r300g is a lot slower on the GPU side than it should be I think. I'll install a few games on Windows XP to verify this, and file a separate bug(or add infos to an existing bug report if one exists).

Created attachment 50875 [details]
dmesg of the r200 machine

Created attachment 50876 [details]
Xorg.log of the r200 machine

This file contains the following lines:
[    36.568] (II) RADEON(0): KMS Color Tiling: enabled
[    36.568] (II) RADEON(0): KMS Pageflipping: enabled

The man page says color tiling and page flipping are implemented on r200. I had to enable color tiling manually, but page flipping was on by default. Enabling color tiling didn't change the performance.

Created attachment 50877 [details]
glxinfo from the r200 machine

(In reply to comment #11)
> The man page says color tiling and page flipping are implemented on r200. I had
> to enable color tiling manually, but page flipping was on by default. Enabling
> color tiling didn't change the performance.

Support for colortiling is not implemented for r1xx or r2xx yet for KMS so enabling it does nothing.  KMS pageflipping is vsynced, so it won't really help with performance; it just reduces memory bandwidth for buffer swaps by pageflipping rather than blitting.

I don't think this is still an issue. DRI2 OpenGL drivers have matured a lot, especially for the R300-R500 GPUs. It's unlikely that the drivers for older GPUs will be improved. Closing.