Has AMD Finally Fixed Tearing With Its Linux Driver?

[phoronix]

Phoronix: Has AMD Finally Fixed Tearing With Its Linux Driver?

AMD put out a rare beta Linux driver this Monday and they have now just announced the release of the Catalyst 11.1 driver as their stable monthly update for Linux and Windows users. With this Catalyst driver, there is though one interesting but hidden feature that is sure to please many ATI/AMD Radeon Linux desktop users.

http://www.phoronix.com/vr.php?view=15655

[allquixotic]

Tear-free is fantastic for watching videos, using your desktop with compiz, and other lightweight tasks. A lot of people will be happy.

The only place where it falls down is actually based on a design limitation. Basically, you use more VRAM, and dramatically increase the latency between frame render and delivering it to the monitor, by ensuring a tear-free experience. So if you have plenty of VRAM, why do you care about latency? Try playing an FPS game.

Yeah, real gamers will be able to feel the difference in lag when they change their viewpoint and it takes a split-second for the rendered frames to catch up. Too bad. I guess I will have to disable tear-free when playing games, and enable it to watch videos with good quality. Because latency is irrelevant with videos, and even mostly irrelevant on the ordinary desktop applications.

You can't blame AMD for this latency, though: it's the only way you can really get a true tear-free experience, because you have to add another layer of buffering. Even on Windows, a truly tear-free game experience comes with added latency, usually by enabling the combined features of "Triple Buffering" and "VSync". With Catalyst Linux Tear-Free, you are essentially getting the hardware equivalent of "Triple Buffering" and "VSync" for all 2d, 3d, and video applications -- every rendered frame running in the X server is triple buffered and vsynced.

[d2kx]

Or you could enable it on-the-fly through AMDCCCLE.

[kirillkh]

Allquixotic +1.
There should be a way to separately disable this feature for 3D apps (most of which are games, anyway), and do it without restarting the X server.

On a side note, the free Radeon driver used to have some kind of solution to tearing, which even worked in 3D, but as far as I can tell, it's been disabled some time ago. I actually complained about game responsiveness problems introduced by this feature on #radeon, and was told that it was NOT sync-to-vblank, but some other mechanism, apparently more lightweight. Now all this is speculation, as I don't really have any firsthand knowledge of the subject. But it makes me wonder if Catalyst could employ a similar mechanism (for xv and 2D) without taxing the memory.

[m4rgin4l]

Just tried it. It works! I opened up a couple of videos and I couldn't see any tearing. The desktop redrawing also seems faster, but I don't know for sure.

[d2kx]

There should be a way to separately disable this feature for 3D apps (most of which are games, anyway), and do it without restarting the X server.

There is, through AMDCCCLE.

[agd5f]

Allquixotic +1.
There should be a way to separately disable this feature for 3D apps (most of which are games, anyway), and do it without restarting the X server.

On a side note, the free Radeon driver used to have some kind of solution to tearing, which even worked in 3D, but as far as I can tell, it's been disabled some time ago. I actually complained about game responsiveness problems introduced by this feature on #radeon, and was told that it was NOT sync-to-vblank, but some other mechanism, apparently more lightweight. Now all this is speculation, as I don't really have any firsthand knowledge of the subject. But it makes me wonder if Catalyst could employ a similar mechanism (for xv and 2D) without taxing the memory.

Wait for vline. You can stall the GPU until scanout has passed a certain line in the scanout image. The downside is, that the GPU has to wait until the vline passes so you're not rendering during that period. With multi-buffering, the GPU is always busy, but it takes more memory since you need a stack of buffers to cycle between to avoid rendering to the buffer being scanned out of.

[monraaf]

Tear-free is fantastic for watching videos, using your desktop with compiz, and other lightweight tasks. A lot of people will be happy.

No, tear-free video playback is something you'd expect from a graphics driver. It's like windshield wipers on a car. You don't go boasting how fantastic this 'new thing' called windshield wipers are on your ATI car. Other people will laugh at you because it's something they have always had on their car and just take for granted.

Furthermore, Xv still has the wrong color space so you get washed out videos and GL has high-cpu usage issues when doing hardware colorspace conversion with some videos.

So sorry to be the party breaker here but the truth is fglrx is still a hassle an pain in the ass for video playback.

[energyman]

good thing I don't even realize that it is a pain in the ass. It works well for me.

[kirillkh]

Wait for vline. You can stall the GPU until scanout has passed a certain line in the scanout image. The downside is, that the GPU has to wait until the vline passes so you're not rendering during that period. With multi-buffering, the GPU is always busy, but it takes more memory since you need a stack of buffers to cycle between to avoid rendering to the buffer being scanned out of.

The obvious solution is then to decide which method to use based on the amount of vram available.