AMD R700 2D Driver Performance Comparison

[Redeeman]

Last I heard, didn't Nvidia's newest drivers produce crummy 2D performance on GeForce 8000 and newer?

In any case, I am totally ecstatic that the EXPERIMENTAL r700 code has already come this far, even surpassing the proprietary Catalyst driver in 2D acceleration. (not that fglx sets the bar very high... )

With any luck, end-users like me will have a working r600/r700 driver when Ubuntu 9.04 comes out.

that depends on what "working" requires.. if it requires opengl 2.1 and stuff, i think you miiigghhtt wanna switch the timetable a tad

this is nice though

[d2kx]

Yeah, I hadn't intended on doing an R700 2D performance look this early, but it was requested by Matthew. It turned out pretty well for a basic implementation

So maybe they decide again on whether they will implement EXA in the fglrx driver. Because this comparison does not show how great RadeonHD is (but it will be, of course), but how slow fglrx is.

[yoshi314]

i thought radeonhd will get beaten on all tests. instead, it appears that fglrx has still numerous performance issues.

i wonder if it's due to complexity of the code, or just bugs. there was a claim that simpler driver might actually beat more complex driver.

[bridgman]

My interpretation of the test results was that "EXA is finally worth implementing"

i thought radeonhd will get beaten on all tests. instead, it appears that fglrx has still numerous performance issues. I wonder if it's due to complexity of the code, or just bugs. there was a claim that simpler driver might actually beat more complex driver.

This is actually a real good example of the relative benefits of open vs closed source. 2D is relatively simple in terms of the amount of code required, so a single good developer can produce a sufficiently optimized driver in a practical amount of time. In that case the open source driver will usually win because it can and will track improvements elsewhere in the stack more quickly (since whoever changes the rest of the stack will probably change the driver at the same time).

3D, by comparison, is maybe 100x the code size (seriously) so there the advantages of being able to share proprietary code across a number of OSes will typically outweigh the benefits of having source code available to developers working on other parts of the stack.

Gallium3D is interesting because (a) it seems to have the API lines in the right place to let relatively small HS-specific code still get decent performance, and (b) there is some cross-OS potential so development effort can bleed in from other OSes and markets.

[energyman]

that circles test result looks fishy. How many test runs were made? Just one or several (and I don't mean gtkperf rounds...)? Maybe it was some background activity? A ubuntu bug or a bug in the pts? Because 4000 seconds.. that is completly out of the loop.

[llama]

Phoronix: AMD R700 2D Driver Performance Comparison

Earlier this week we delivered results from a comparison between the Catalyst and X.Org Radeon drivers looking at the R500 2D performance. With a lot of interest having been generated from that, we have now carried out the same set of tests again but this time using an ATI Radeon HD 4850 (RV770) graphics card and the experimental EXA support.

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

Very interesting results. Your conclusion is a little funny, though: The important thing isn't which driver won more benchmarks. It's which driver had big slowdowns that will be a bottleneck for some real-world activities and e.g. make firefox feel slow.

There were only a few cases where one driver was much slower than the other. IMHO, you should be focusing on those. e.g. Catalyst took 0.09s vs. radeonhd's 0.12s on GtkTextView scrolling. Text scrolling is definitely something that can make a desktop feel slow. e.g. server mobos with onboard mach64 chips suck so much with gnome-terminal that xterm is preferable. (Fortunately, the newer ATI E1000 chipset is up to par and can run a gnome desktop pretty well. No 3D accel, though, since the HW omits that functionality!)

[energyman]

well, gnome sucks anyway ....

[Enverex]

that circles test result looks fishy. How many test runs were made? Just one or several (and I don't mean gtkperf rounds...)? Maybe it was some background activity? A ubuntu bug or a bug in the pts? Because 4000 seconds.. that is completly out of the loop.

The fglrx driver sucks on that test and one of the other tests. I tried it myself on my HD4850 and it took a very long time.

Also don't bother with more comments like your last about Gnome, that is just pointless trolling.

[tmpdir]

well, gnome sucks anyway ....

Than you'll love this article

thread=15059

[makomk]

Very interesting results. Your conclusion is a little funny, though: The important thing isn't which driver won more benchmarks. It's which driver had big slowdowns that will be a bottleneck for some real-world activities and e.g. make firefox feel slow.

There were only a few cases where one driver was much slower than the other. IMHO, you should be focusing on those. e.g. Catalyst took 0.09s vs. radeonhd's 0.12s on GtkTextView scrolling. Text scrolling is definitely something that can make a desktop feel slow. e.g. server mobos with onboard mach64 chips suck so much with gnome-terminal that xterm is preferable. (Fortunately, the newer ATI E1000 chipset is up to par and can run a gnome desktop pretty well. No 3D accel, though, since the HW omits that functionality!)

I think text scrolling often involves copies with overlapping source and destination, and the current code for that in the radeonhd r6xx-r7xx-support branch is less than ideal. (More specifically, it does the copy a line/column at a time.)