Shader Optimization Back-End Might Go In For R600g

[phoronix]

Phoronix: Shader Optimization Back-End Might Go In For R600g

For many months there has been a "shader optimization" branch of Mesa/R600g that sought to rather noticeably boost the performance of the AMD R600 Gallium3D driver. While this work by Vadim Girlin didn't look like it would be merged, after being revived and cleaned-up, it might reach mainline Mesa/Gallium3D as a new performance-boosting option...

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

[smitty3268]

For those too lazy to look up the link

It probably won't make much of a difference on Quake3, but here are some results:

Oh, and in case it wasn't clear from Michael's article, this code runs on the hardware instructions, which means it can be run after getting the output of either the old compiler backend or the new llvm one. It doesn't care about that.

Below are some quick benchmarks for shader performance and compilation
time, to demonstrate that currently r600-sb might provide better
performance for users, at least in some cases.

As an example of the shaders with good optimization opportunities I used
the application that computes and renders atmospheric scattering
effects, it was mentioned in the previous thread:

http://lists.freedesktop.org/archives/mesa-dev/2013-February/034682.html

Here are current results for that app (Main.noprecompute, frames per
second) with default backend, default backend + r600-sb, and llvm backend:
def def+sb llvm
240 590 248

Another quick benchmark is an OpenCL kernel performance with bfgminer
(megahash/s):
llvm llvm+sb
68 87

One more benchmark is for compilation speed/overhead - I used two piglit
tests, first compiles a lot of shaders (IIRC more than thousand), second
compiles a few huge shaders. Result is a test run time in seconds, this
includes not only the compilation time but anyway shows the difference:
def def+sb llvm
tfb max-varyings 10 14 53
fp-long-alu 0.17 0.38 0.68

This is especially important for GL apps, because longer compilation
time results in the more significant freezes in the games etc. As for
the quality of the compiled code in this test, of course generally llvm
backend is already able to produce better code in some cases, but e.g.
for the longest shader from the fp-long-alu test both backends optimize
it to the two alu instructions.

Of course this branch won't magically make all applications faster, many
older apps are not really limited by the shader performance at all, but
I think it might improve performance for many relatively modern
applications/engines, e.g. for the applications based on the Unigine and
Source engines.

[curaga]

Please merge, and make it the default for 9.2. The lack of an optimizing r600 backend for all this time has been a huge bottleneck, the elephant in the room.

[Ibidem]

I'd be interested to see 3-way benchmarks for this (r600g with or without r600-sb, fglrx). Not necessarily a full benchmark, just Unigine, a couple older games, and perhaps an opencl benchmark, if there is one already.

It's sounding like it brings r600g close to Catalyst in terms of performance.

[stalkerg]

WOW! Now I can use High shaders for StarCraft2 under Wine. r600-sb very cool! Need merge now and enable by default.

[Pontostroy]

I'd be interested to see 3-way benchmarks for this (r600g with or without r600-sb, fglrx). Not necessarily a full benchmark, just Unigine, a couple older games, and perhaps an opencl benchmark, if there is one already.

It's sounding like it brings r600g close to Catalyst in terms of performance.

unigine 3.0
r600 - 558
r600-sb - 784
windows 7 - 789

[brosis]

unigine 3.0
r600 - 558
r600-sb - 784
windows 7 - 789

WOW! Respect!!

[smitty3268]

That's awesome

unigine 3.0
r600 - 558
r600-sb - 784
windows 7 - 789

What card?

[Pontostroy]

What card?

hd6770
heave 3.0 1920x1080 opengl

[Nuc!eoN]

unigine 3.0
r600 - 558
r600-sb - 784
windows 7 - 789

What about heat production?