Comment 6 for bug 544496

Updating this report with more recent experiences:

On Mar. 8 I upgraded from Mesa 7.8 (git be1b7d1) to Mesa 7.9-devel (git 3ca9336), and notice an all around performance increase. Immediately following that, I built, installed, and booted the newly-released 2.6.34-rc1 kernel.

Just booting that new kernel to a command-line-only runlevel revealed a noticeable performance improvement. Running X revealed that the performance gains were across the board: everything was running faster.

I've been building my own xf86-video-ati packages with the "vline" feature reverted, but with these performance gains I decided to test it again.

I built and ran radeon from git commit 3a44f1c (Mar. 9) in two versions -- one with "vline" reverted, and one with "vline" included. As before, the "vline" version is perceivably more sluggish than the version with that feature reverted. However, the most dramatic differences in my original post here were seen in the game 'torcs'; when I tried that game again, it was playable this time (last time, the sluggishness made it nearly impossible to play). Interestingly, I reported before that the 'torcs' frame rate seemed to be capped at 30 fps (half my monitor's vert refresh rate), but this time the game was often able to jump into the 50 fps range for short bursts.

Other apps I've been testing with, besides 'torcs', are also affected negatively... but less noticeably so.

The "vline" feature itself definitely works as intended. No cutting/tearing ever occurs. I wasn't having bad problems with tearing without "vline," but in games like 'torcs' (and even 'prboom') the difference is noticeable. I definitely prefer the "vline" version for clarity, but the "no-vline" version still outperforms it enough that I'll be sticking with my git branch with the reversion for a little while longer.

I am using quite fast hardware here, Radeon HD 4850, so I wouldn't be surprised if less powerful cards were impacted more seriously.