AMD R600 LLVM GPU Back-End Gets Better

[phoronix]

Phoronix: AMD R600 LLVM GPU Back-End Gets Better

This week was marked by quite a steady patch flow of improvements to the AMD R600 GPU LLVM back-end that's used for Radeon Gallium3D OpenCL support and is also being bettered for its handling of OpenGL...

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

[Drago]

Michael, yes LLVM backend is nice, but too far in the future. Vadim's patch already looks awesome, and it should be benchmarked.
His initial benchmark:
Heaven 3.0, all settings high/enabled, 1280x720, HD5750:
default backend : 20.0 fps
llvm backend : 18.8 fps
r600-sb : 38.0 fps

This could end up as one hell of a news for you. And this time make sure there is test for more real game, like...Doom3 and not the old toy engines which run already fine on r600g.

[uid313]

While I am on a Nvidia card, it is really nice to see all this progress going into the AMD open source device drivers.

Work on nouveau seems to be going ahead pretty slowly.
I read all the time about new stuff happening in the AMD open source driver.

It sounds very promising.

[mcgreg]

What is the current/future benefit of this?

I have a AMD 6850 - what can I do now with it I couldn't do before? I mean in general with this LLVM GPU stuff.

[bridgman]

What is the current/future benefit of this?

I have a AMD 6850 - what can I do now with it I couldn't do before? I mean in general with this LLVM GPU stuff.

When we (re)started the open source effort we made some early estimates about potential performance levels given the size of the development community and what would be feasible with that number of developers. Our estimate was 60-70% of Catalyst performance on average (simple apps faster, complex apps slower), with some of the performance gap coming from having a fairly simple shader compiler / translator in the open source stack.

This kind of work offers the potential for significantly higher performance on apps with complex shaders, or in some cases to run some apps successfully where previously the shaders could not be be made to work on the hardware due to register limitations etc...

Vadim's test results on Heaven (above) offer an extreme example of what is possible -- I say extreme only because the Unigine demos are pretty demanding so shader compiler improvements are likely to have the most effect there.

[mcgreg]

Hallo bridgman,

thx for your answer

But actually you didn't answer my question like I wanted to.
It was more like: are there any real applications that make use of it?
For example ... Chromium? any parts on linux/desktop environment/video+music decoder/encoder? Are there already application that use that technology?
Will this technology be used "on the fly" or will I need any special version to make it work?

And is the "driver" already in the state to just work out of the box? Are there applications yet that work already with "the current version"?

Sorry If I am asking too many question, but I am pretty much confused about the stuff.

[necro-lover]

It was more like: are there any real applications that make use of it?

Oil-Rush is a game based on unigine engine this means this game run faster.

That is a real application.

[bridgman]

The compiler should be invisible to applications other than the changes I mentioned -- more efficient shader execution and possibly allowing more complex apps to run on the HW without running out of hardware resources (typically registers) available to shader programs.

The inputs and outputs to the shader compiler aren't changing (TGSI at the input, HW ISA at the output) - the only change is hopefully doing a better job of compilation ie generating more efficient HW ISA programs to run on the hardware. The shader compiler is usually invoked "on the fly" when the application calls glCompileShader (at least that was the call last time I had time to play with OpenGL

Last time I looked at the LLVM compiler (months ago) there was a build option (--enable-r600-llvm-compiler) required to include the llvm shader compiler alongside the current shader compiler. Other than making sure the llvm code is built into mesa no special version of the driver is required other than "later is probably better".

There was also a runtime switch (R600_USE_LLVM environment variable) required to choose the LLVM-based compiler rather than the original one. I don't know current status, ie whether the LLVM shader compiler is either built by default or used by default if present.

Note that for SI the LLVM-based shader compiler is the default and only option.