Announcement

Collapse
No announcement yet.

AMD R600 LLVM GPU Back-End Gets Better

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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.

    Comment


    • #3
      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.

      Comment


      • #4
        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.

        Comment


        • #5
          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; 16 February 2013, 08:55 AM.
          Test signature

          Comment


          • #6
            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.

            Comment


            • #7
              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.

              Comment


              • #8
                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; 16 February 2013, 01:29 PM.
                Test signature

                Comment

                Working...
                X