Results 1 to 8 of 8

Thread: AMD R600 LLVM GPU Back-End Gets Better

  1. #1
    Join Date
    Jan 2007
    Posts
    15,113

    Default AMD R600 LLVM GPU Back-End Gets Better

    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

  2. #2
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    526

    Default

    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.

  3. #3
    Join Date
    Dec 2011
    Posts
    2,103

    Default Nice

    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.

  4. #4
    Join Date
    Sep 2007
    Posts
    80

    Default

    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.

  5. #5
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    Quote Originally Posted by mcgreg View Post
    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.
    Last edited by bridgman; 02-16-2013 at 07:55 AM.

  6. #6
    Join Date
    Sep 2007
    Posts
    80

    Default

    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.

  7. #7
    Join Date
    Aug 2012
    Posts
    292

    Default

    Quote Originally Posted by mcgreg View Post
    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.

  8. #8
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    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.
    Last edited by bridgman; 02-16-2013 at 12:29 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •