Please report to upstream if not already reported. Thanks.

check dmesg log what it in there when the drm module is loaded.

Even with 2.6.35.4-2 the issue is not fixed.

If I add kernel options "radeon.dynclks=1 radeon.dynpm=1" (what is default for me), KMS is not even used (and the non-KMS glxgears framerate is about 4 times less than on the 2.6.34 without KMS). Without these options, KMS is used, but still glxgears frame rate is slow.

@DoDo:
What is your screen refresh rate? I bet it's 60Hz. Does glxgears say that framerate is synchronized to vsync? In this case the FPS you are getting are normal. See more here: https://bbs.archlinux.org/viewtopic.php?id=99554.

Can you post the output of glxinfo | grep -i opengl?

How does KWin compositing work: does it use OpenGl, like compiz, or mostly software rendering?
E.g. for me xfwm4 (software) compositing works much faster on geforce 4 mx440 (=geforce 2 something) with nouveau (no opengl), than on the same card using nvidia-96xx and on radeon xpress 200m (a better card). Two latter drivers use full 3D accel. Also, FPS(nvidia-96xx) >> FPS(nouveau) > FPS(ati). So what?

@Leonid

Yes, you're right: my screen refresh rate is 60 Hz, and glxgears says that framerate is synchronized to vsync.

But:
*) with 2.6.34 glxgears reports the same, and still has 1000+ FPS. How's that then possible?
*) with 2.6.34 kwin composing with OpenGL works fine, and with 2.6.35 KDE reports that it has disabled compositing because the rendering was too slow (I have no games installed on my laptop so I haven't tried with games)
*) no matter of using 2.6.34 or 2.6.35, glxinfo | grep -i opengl reports:
OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 (RV530 71C5) 20090101 TCL DRI2
OpenGL version string: 1.5 Mesa 7.8.2

Since my desktop PC with Nvidia graphics is not affected, I'd say it's a regression bug in xf86-video-ati driver (and link you gave me suggests that the same happens also with xf86-video-intel: then the problem has to be in some component that is common to both ati and intel driver)

>with 2.6.34 glxgears reports the same, and still has 1000+ FPS. How's that then possible?

Good question. My understanding is that glxgears measures the rate, at which it can repaint the screen. If 60 times/sec is the hw/driver limit, what is the meaning of 1000+ FPS? Btw, I am also getting (RV482) ~200 FPS w/o KMS, however, w/ KMS it is ~59.

>with 2.6.34 kwin composing with OpenGL works fine, and with 2.6.35 KDE reports that it has disabled >compositing because the rendering was too slow

Is there any way to override this (I don't have KDE)? Is this
https://bbs.archlinux.org/viewtopic.php?pid=815841 the same issue?

>OpenGL renderer string: Mesa DRI R300 (RV530 71C5) 20090101 TCL DRI2

At least driver works (I assume there are no errors in kernel.log). As a side note you don't have AMD cpu do you (I just noticed that in the Mesa line there is no MMX/3DNow)?

>Is there any way to override this (I don't have KDE)?
You can override it, but the desktop responsiveness is slow then, because the rendering is slow. You see: general 3D acceleration (composition or not) is slow with 2.6.35 - few times slower than with 2.6.34.

> My understanding is that glxgears measures the rate, at which it can repaint the screen.
I think it measures the how many times it can draw the gears in one second, and not how many times it can repaint the screen. If the latter were true, then glxgears would report ~60 FPS for any graphics card and any driver, but as I said: with 2.6.34 my driver renders glxgears at 1000+ FPS, in the times of using fglrx with my laptop, glxgears rendered 3000+ FPS (FLOSS driver is still much slower than catalyst driver) and my desktop PC with powerful Nvidia graphics renders 15000+ FPS on glxgears on LCD monitor with 60 Hz refresh rate.

> At least driver works (I assume there are no errors in kernel.log). As a side note you don't have AMD cpu do you (I just noticed that in the Mesa line there is no MMX/3DNow)?
I've seen no errors in kernel.log and I'm using Intel Core 2 Duo processor (although while using ubuntu there was SSE in Mesa line and here on Arch there isn't - interesting...).

Have you tried EnablePageFlip and EXAPixmaps in xorg.conf? If these don't take effect, you have no choice other than follow the first comment in the thread.

As a side note, VERY loosely speaking, think of 60Hz as a max rate, at which current can pass through the screen to light those pixels. As an experiment you can run some heavy 3D game, like MS Flight Simulator X or Call of Duty 4, at max resolution -- if your "powerful" nvidia gives 15-20FPS, it would mean you have a decent card. The only situation, when you should pay attention to glxgears, is when FPS << vsync (e.g. 30 FPS vs 60 Hz on a desktop). Also, if you disable KMS + (via xorg.conf) AIGLX + DRI, I bet you will see an increase in FPS, which is clearly meaningless, since you have no support of OpenGL now.

> Have you tried EnablePageFlip and EXAPixmaps in xorg.conf?
No. I don't use xorg.conf at all, because Xserver 1.8 correctly sets up all parameters I need (at least in kernel version <= 2.6.34 :P )

> Also, if you disable KMS + (via xorg.conf) AIGLX + DRI, I bet you will see an increase in FPS, which is clearly meaningless, since you have no support of OpenGL now.
OK, OK, enough about glxgears - it isn't a real benchmark after all. The real question is: why kwin composition doesn't work with 2.6.35 and works with 2.6.34? It's obviously a bug in 2.6.35...

Any progress with 2.6.35.6 ?

> ... because Xserver 1.8 correctly sets up all parameters...
Since when?

I have a similar issue with my X200m ati card for a while. glxgears also reports ~60fps due to vsync. This is probably a kernel ati drm module related issue. You should report it upstream to the kernel tracker! Maybe check .36rc kernels first or even drm-next from AUR.

For me the broken vsync doesn't show any effect. Xfce 2D desktop is still fast enough even with its internal compositor. But I have 3d issues with badly broken textures since a while in all 3D games (e.g.supertuxcart). Assigning also to myself beeing responsible for the Ati stack.

Thanks, Andreas.

Some comments though:
(1) vsync isn't broken
It works (perhaps finally) as it should, because FPS above screen refresh rate are being cut off. This is "random" without vsync and "in-phase" (controlled by CPU/GPU) with vsync. Thus, in the first case you may get blurred picture.
(2)Should FPS affect XFCE compositing (it does not use OpenGL)? I have the same card as you, and glxgears are broken (no gears) with XFCE compositor :( Don't know when it started, however...
(3) I still remain confused as of which bugzilla this issue belongs to? Kernel of freedesktop? Or they are the same?

We have new .36 kernel, new Xorg and new MESA in testing. Everything is working well for me expect 3D games work still quiet slowly but render well now for me.

How's the state for the initial reporter now?

I'll try ASAP (probably on Monday or Tuesday), because I'm currently too busy with other things.

2.6.34 still works better for me...

Please file an upstream bug. It's works well for me and everybody else. Maybe only your hardware is the reason. There's probably nothing we can do at Arch packaging level.

ok

How's state with current Arch kernel .36.2? Have you tried .37rc kernels? Have you made an upstream report we can follow?

In the meantime new ati-dri arrived, which brought gallium driver. This one works relatively fine. With 2.6.34 glxgears showed over 1600FPS, but with 2.6.36 only 58 FPS. As glxgears isn't real benchmark, I tried with nexuiz. On 2.6.34+gallium there were only 5 FPS, but with the 2.6.36-1 cca 20 FPS. With 2.6.36-2 and newest updates (as of yesterday), FPS in nexuiz dropped to 8 FPS (Mobility Radeon X1600 - resolution 1680x1050; normal effects), so there might be a regression somewhere (either in kernel or in ati-dri). Kwin OpenGL composition doesn't work as it worked with 2.6.34+oldMesa (not gallium), but AFAIK this problem is known. The problem appears as gallium driver advertises some extensions which it doesn't support very well, and Kwin has problems with this. While waiting this to be fixed, I've enabled Kwin's Xrender compositor (I can't live without desktop grid and present windows effects).

P.S. Sorry for being a noob, but I've always reported bugs to the official tracker of the distribution I've been using. How can I file an upstream bug? On which tracker should I report the issue?

To check and compare behavior with classic mesa vs. gallium use abs and recompile mesa and change it back to use the classic mesa driver, maybe rebuild the xf86-video-ati driver. Then you should know if one or both 3d stacks are broken. Then also test various kernel drm modules. Maybe also test drm-next from AUR. Always remember kms + gallium is the future and should work in the end. Upstream will not spend much time on the classic drivers anymore.

For more help ask in the #radeon irc channel if it should finally be reported to mesa bugs http://www.mesa3d.org/bugs.html or to the kernel bugtracker to the drm kernel module.

Thanks for the tip, but I did compile mesa once and it took ages. I really don't have time to do all the testing you mentioned. I'm quite satisfied with working suspend/hibernate and possibilty to watch video on my laptop. I do all 3D stuff now on my PC, which has nvidia graphics that doesn't make any problems. It would be nice to have working opengl accelerated desktop, but it's not a necessity (at least not now while I have more important things to do). I also don't use my laptop for gaming so it's really not so much important for 3D to work properly (but it would be nice).

I'll just keep updating my laptop with arch's regular updates and hope this will be fixed some day, but I really, really don't have time to rebuild mesa and ati driver just to make few tests. Sorry about that.

Btw. the Gallium KDE problem I mentioned earlier is discussed here: http://www.phoronix.com/forums/showthread.php?t=25907#post145822

If you don't have an interest to locate the problem further I can close this bug?

Yes, please close it as WONTFIX.