AMD R600 Gallium3D Optimizing Back-End Merged

[phoronix]

Phoronix: AMD R600 Gallium3D Optimizing Back-End Merged

Vadim Girlin's shader-optimizing back-end for the AMD R600 Gallium3D driver has been merged into mainline Mesa...

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

[ChrisXY]

r600g/sb: initial commit of the optimizing shader backend -0/+17498
I don't know how much of that is autogenerated, but it sure looks like a bigger chunk of work, so of course a big thanks who make stuff like this possible.

Will this be usable for radeonsi in the future too?

edit: Even with documentation!

http://cgit.freedesktop.org/mesa/mesa/plain/src/gallium/drivers/r600/sb/notes.markdown

[pingufunkybeat]

Phoronix: AMD R600 Gallium3D Optimizing Back-End Merged

Vadim Girlin's shader-optimizing back-end for the AMD R600 Gallium3D driver has been merged into mainline Mesa...

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

This is the patchset which brings Unigine Heaven to Windows 7 performance.

Things just keep getting better and better!

And to think that OpenCL is making progress and that the PM code has already been written and is awaiting release.... W00t w00t!

[meklu]

Looks like I may have to start considering using the FOSS drivers.

[kernelOfTruth]

This is the patchset which brings Unigine Heaven to Windows 7 performance.

Things just keep getting better and better!

And to think that OpenCL is making progress and that the PM code has already been written and is awaiting release.... W00t w00t!

just took Shank2 for a test-run and it's really noticably more fluid (e.g. the llvm-backend gained some small noticable improvement but with Vadim Girlin's tweaks performance really seems to shine

would be interesting to see in the long-run how stability is with R600_DEBUG=sb

w00t w00t !

[przemoli]

r600g/sb: initial commit of the optimizing shader backend -0/+17498
I don't know how much of that is autogenerated, but it sure looks like a bigger chunk of work, so of course a big thanks who make stuff like this possible.

Will this be usable for radeonsi in the future too?

edit: Even with documentation!
http://cgit.freedesktop.org/mesa/mes...notes.markdown

Unlykly.

AMD devs want to utilise LLVM for all the low level stuff in their drivers, while this code is custom made. That is also why AMD devs have trouble with accepting this code. That would mean supporting unfamiliar code, while they want to focus on LLVM.

And since its just r600g it wont work for radeonSI, and even if its highly succesfull for r600g gen hardware, radeonSI support different hw, so what works for r600g-sb may not work for newer GPU's.

[Ericg]

Unlykly.

AMD devs want to utilise LLVM for all the low level stuff in their drivers, while this code is custom made. That is also why AMD devs have trouble with accepting this code. That would mean supporting unfamiliar code, while they want to focus on LLVM.

And since its just r600g it wont work for radeonSI, and even if its highly succesfull for r600g gen hardware, radeonSI support different hw, so what works for r600g-sb may not work for newer GPU's.

They have said before that this code is just a stop-gap measure. They know its not the longterm solution. But the longterm (LLVM) solution is better than the current solution, BUT this solution is better than the longterm one right now. Its being merged knowing full well that it will be bin'ed once LLVM is optimized and under better handling.

[pingufunkybeat]

AMD devs want to utilise LLVM for all the low level stuff in their drivers, while this code is custom made.

I thought that this work ran very late, on HW instructions, so it can be run with LLVM too.

Of course that the optimisations themselves will eventually be done by LLVM as its backend improves. In the meantime, this can run after LLVM generates HW instructions, it doesn't hurt anything there.

[Drago]

I thought that this work ran very late, on HW instructions, so it can be run with LLVM too.

Of course that the optimisations themselves will eventually be done by LLVM as its backend improves. In the meantime, this can run after LLVM generates HW instructions, it doesn't hurt anything there.

IIRC, there were cases where LLVM+r600-sb, made bad result against r600-sb alone.

[smitty3268]

IIRC, there were cases where LLVM+r600-sb, made bad result against r600-sb alone.

That's true, but i think at least 1 of those problems has already been addressed. I'm not sure if they all have or not, or whether it's mostly helpful with only a few regressions or if it has lots of problems.

Sounds like a good thing for Michael to test.

/ i'm going to cry when michael's tests only consist of the quake 3 engine.