Announcement

Collapse
No announcement yet.

R600 Gallium3D Disables LLVM Back-End By Default

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

  • #11
    Originally posted by 89c51 View Post
    Does this also mean that r600 will never get FOSS OpenCL ?? (when and if ready)
    No it does not. The LLVM work on VLIW was originally intended for compute paths only, not graphics paths, but Tom was using graphics paths to test the new compiler code before an OpenCL framework was available. The results (graphics + llvm + VLIW) looked sufficiently promising to pursue further. Compute paths would continue to use llvm AFAIK.
    Test signature

    Comment


    • #12
      Originally posted by edoantonioco View Post
      Does this means less performance? And are we talking about mesa 10.2?, because its not explained.
      It won't affect performance. llvm has never been enabled by default in r600g. The llvm support in r600g was only originally intended to support OpenCL, it was just enabled optionally for OpenGL for testing purposes, but it never got full support for a lot of the features required for OpenGL. What this patch does is disable OpenGL llvm support by default when it's enabled in the driver.

      Comment


      • #13
        As far as I remember, the LLVM backend has always been slower on R600 since Vadim's backend was merged. Why people think LLVM should be faster is a mystery to me.

        Comment


        • #14
          Some time ago in mesa 9.2 there was a new feature (the r600 back-end) that bring better performance, but it was disabled by default (enabled by default in 10.0). I activate that feature with
          R600_DEBUG=sb,nollvm
          and the performance was better, but if I did this
          R600_DEBUG=sb
          the performance was even better.
          That means than the LLVM stuff meant more performance. Thats why I was curious about how the performance would be affected now than the feature is going to be disabled.

          Comment


          • #15
            Does this mean we shouldn't expect llvmpipe to reach parity with the hardware drivers for some time? Is the reason for these features not being implemented because of an issue with upstream, with the current implementation of llvm, or with the codebase?

            Comment


            • #16
              Originally posted by liam View Post
              Does this mean we shouldn't expect llvmpipe to reach parity with the hardware drivers for some time? Is the reason for these features not being implemented because of an issue with upstream, with the current implementation of llvm, or with the codebase?
              This has nothing to do with llvmpipe, or even radeonSI.

              It's about the r600 backend inside llvm, which isn't as good as the compiler and sb optimizer inside mesa's r600g driver. Nothing else.

              And the reason it's not is because no one is really working on it - everyone on the llvm side is busy getting OpenCL and the radeonSI driver working. Nobody cares about getting it working for r600g because that driver already works without it.
              Last edited by smitty3268; 18 April 2014, 02:16 AM.

              Comment


              • #17
                Originally posted by marek View Post
                Why people think LLVM should be faster is a mystery to me.
                I think its more along the lines of people think LLVM should be faster eventually and could be made to be faster. LLVM brings to the table quick compilation, ontop of a full compiler that can be optimized to be very platform specific. With at least a chance of getting free performance bumps from optimizations made to other parts of LLVM.

                Contrastly Vadim's work, while VERY appreciated and applauded, is a compiler that was written by one person for one task and currently receives an unknown amount of attention and optimization. Meanwhile the development effort on LLVM is known.

                Also there's the issue of LLVM's expanding usage in many things and the assumption that comes with that growth that LLVM would be flexible enough to handle anything and everything, including graphics shader work.
                All opinions are my own not those of my employer if you know who they are.

                Comment


                • #18
                  Originally posted by Ericg View Post
                  I think its more along the lines of people think LLVM should be faster eventually
                  Faster than what?

                  Comment


                  • #19
                    Originally posted by dee. View Post
                    Faster than what?
                    Vadim's sb compiler
                    All opinions are my own not those of my employer if you know who they are.

                    Comment


                    • #20
                      Originally posted by Ericg View Post
                      I think its more along the lines of people think LLVM should be faster eventually and could be made to be faster. LLVM brings to the table quick compilation, ontop of a full compiler that can be optimized to be very platform specific. With at least a chance of getting free performance bumps from optimizations made to other parts of LLVM.

                      Contrastly Vadim's work, while VERY appreciated and applauded, is a compiler that was written by one person for one task and currently receives an unknown amount of attention and optimization. Meanwhile the development effort on LLVM is known.

                      Also there's the issue of LLVM's expanding usage in many things and the assumption that comes with that growth that LLVM would be flexible enough to handle anything and everything, including graphics shader work.
                      I don't think most people really give it that much thought. LLVM has become a buzzword. People see it and automatically think it must be better.

                      Also, there's the whole thing of having the SI driver use it. People think if the newer driver is requiring it, there has to be a good reason they went that way, and in the realm of 3d drivers that often equates to better performance.

                      Comment

                      Working...
                      X