Announcement

Collapse
No announcement yet.

R600 Gallium3D LLVM Compiler Back-End Benchmarks

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

  • R600 Gallium3D LLVM Compiler Back-End Benchmarks

    Phoronix: R600 Gallium3D LLVM Compiler Back-End Benchmarks

    In the past few days after having delivered R600 Gallium3D benchmarks of the R600 SB back-end that is a new shader optimization back-end for the Radeon Gallium3D driver, here's some comparison benchmarks against the upcoming R600 LLVM back-end...

    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
    Honestly the takeaway is... Either one is better than what we're currently dealing with. LLVM, while currently slower than sb, is probably much easier to work with and more generic (in good and bad ways) and going to be much more fine-tuned and optimized in the future given that it is going to be used for OpenCL as well. So yes, for right now, sb is faster. But it wouldn't surprise me if in the future LLVM is just as fast, or faster, and has more active development.

    Another issue that Michael didn't mention was whether or not sb is rendering correctly. I know a few users the other day were complaining that sb was giving incorrect output (which would scew performance numbers). LLVM since it will be getting more attention and be better maintained will hopefully never have these problems down the line.
    All opinions are my own not those of my employer if you know who they are.

    Comment


    • #3
      They aren't mutually exclusive

      The R600 SB back-end that's found with the upcoming Mesa 9.2 isn't enabled by default (it requires setting the R600_DEBUG=sb environment variable), since AMD developers view the R600 LLVM back-end as the future.
      Just to point out - the R600_DEBUG=sb optimization works with the LLVM backend just as well as with the default non-LLVM one. Well, maybe not quite as good, but generally I think they end up with about the same performance in the end.

      Comment


      • #4
        Originally posted by smitty3268 View Post
        Just to point out - the R600_DEBUG=sb optimization works with the LLVM backend just as well as with the default non-LLVM one. Well, maybe not quite as good, but generally I think they end up with about the same performance in the end.
        Thanks for the correction smitty. Though I wonder what kind of latency doing a double-compile (stock -> LLVM -> sb; instead of stock -> LLVM, or stock -> sb) adds. I wouldn't think it would be a LOT but I wonder if it would be enough to be noticable in the form of jittering or stuttering.
        All opinions are my own not those of my employer if you know who they are.

        Comment


        • #5
          Originally posted by Ericg View Post
          Honestly the takeaway is... Either one is better than what we're currently dealing with. LLVM, while currently slower than sb, is probably much easier to work with and more generic (in good and bad ways) and going to be much more fine-tuned and optimized in the future given that it is going to be used for OpenCL as well. So yes, for right now, sb is faster. But it wouldn't surprise me if in the future LLVM is just as fast, or faster, and has more active development.
          LLVM is not suitable for VLIW and it is unlikely that will ever be.

          Comment


          • #6
            I just tried sb backend with GTA IV on wine and must say that it works better than llvm. With llvm I have black rectangle instead of car lights and same with water. Also I seen some flashing textures.When enable R600_DEBUG-sb,nollvm game run little faster and without graphics problem.

            I have radeon 5770 and mesa-git kernel 3.10

            Comment


            • #7
              Originally posted by stalkerg View Post
              LLVM is not suitable for VLIW and it is unlikely that will ever be.
              The tests right here show that it's better than the default compiler, or did you miss that?

              Comment

              Working...
              X