Using The New Radeon Gallium3D 2D Color Tiling

[phoronix]

Phoronix: Using The New Radeon Gallium3D 2D Color Tiling

Patches finally arrived last week for 2D color tiling in the Radeon R600 Gallium3D driver. The patches were then re-based this past weekend and benchmarked by Phoronix. Will the 2D color tiling patches, which affect the Linux kernel, Mesa, libdrm, and xf86-video-ati DDX make the more recent Radeon graphics cards more competitive under open-source to the Catalyst driver?

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

[Nedanfor]

Thank you Michael for these benchmarks Once the bugs are fixed, I hope that there will be a good (~20-30%) performance improvement, but now all we can do is to test the patches to speed up the development. AMD's opensource drivers are becoming, month after month, more suitable for general purpose use.

[Azpegath]

I agree, exciting times for us in the Radeon camp! Perhaps some testing is needed? I have an ASUS RADEON HD4850 with 512MB of memory.

[FourDMusic]

Way to go devs!!! And thank you Michael for the current status of the project. While it is not currently a work of art, I'm sure it will get there. I can't wait until this is more stable ~ excited to test it out! HD5770

[gururise]

Agreed! This is good news. Thanks Michael for keeping us abreast on Radeon driver developments, and thanks to the dev's for the hard work!

[Kano]

I see absolutely no purpose in a benchmark when one driver does not render the same things as the other one does. Those numbers are just wrong and it is even wrong to publish em - it is logical that when you leave out something that it will be faster. In a test without rendering artefacts the speed was not better, so i do not get why somebody should be excited...

[gururise]

I see absolutely no purpose in a benchmark when one driver does not render the same things as the other one does. Those numbers are just wrong and it is even wrong to publish em - it is logical that when you leave out something that it will be faster. In a test without rendering artefacts the speed was not better, so i do not get why somebody should be excited...

Cause if he posted an article without benchmarks, there would be people complaining about the lack of benchmark numbers. He also states quite clearly in the article that the numbers are wrong and to take them with a grain of salt.

[Kano]

And you really think the posters above did notice that as well?

[smitty3268]

And you really think the posters above did notice that as well?

Well, most of them mentioned bugs or testing things out. And one person said he hoped for a 20-30% gain after it was done, which suggests they aren't blindly accepting a 100%+ increase like you seem to think they are.

This is a damned-if-you-do, damned-if-you-don't situation for Michael. I think the explanation in the text was clear enough i have no problem with it. At least he didn't trumpet 100% performance gain in the article title, only to bait and switch inside with the fine print.

[Veerappan]

Well, most of them mentioned bugs or testing things out. And one person said he hoped for a 20-30% gain after it was done, which suggests they aren't blindly accepting a 100%+ increase like you seem to think they are.

This is a damned-if-you-do, damned-if-you-don't situation for Michael. I think the explanation in the text was clear enough i have no problem with it. At least he didn't trumpet 100% performance gain in the article title, only to bait and switch inside with the fine print.

Agreed. Michael stated straight out that there were rendering issues, to view the numbers with skepticism, and also that this is the reason that he didn't run a full panel of tests.

I would also be happy if this led to a 30+% increase when things are finished and cleaned up. If it does lead to something closer to 100%, that'd be awesome. But at this point, we don't know what the final numbers would be. We do have something that lets us guess at the upper-end of what we might expect.