Announcement

Collapse
No announcement yet.

R600 Gallium3D Disables LLVM Back-End By Default

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

  • R600 Gallium3D Disables LLVM Back-End By Default

    Phoronix: R600 Gallium3D Disables LLVM Back-End By Default

    AMD has decided to disable the LLVM compiler back-end by default within the R600 era Gallium3D graphics driver...

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

  • #2
    Does this means less performance? And are we talking about mesa 10.2?, because its not explained.
    Last edited by edoantonioco; 04-16-2014, 10:57 PM.

    Comment


    • #3
      Originally posted by edoantonioco View Post
      Does this means less performance? And are we talking about mesa 10.2?, because its not explained.
      It means worse performance, but better compatibility. And yes, we're talking about Mesa 10.2. Any change to Mesa that isn't a bug fix is assumed to be for the next version.

      Comment


      • #4
        Originally posted by Plombo View Post
        It means worse performance, but better compatibility. And yes, we're talking about Mesa 10.2. Any change to Mesa that isn't a bug fix is assumed to be for the next version.
        Are you sure there's a performance hit ? My recollection was that Vadim's "sb" option was running at about the same speed as llvm, and I believe it was enabled by default.

        Comment


        • #5
          Originally posted by bridgman View Post
          Are you sure there's a performance hit ? My recollection was that Vadim's "sb" option was running at about the same speed as llvm, and I believe it was enabled by default.
          Ah, you're probably right. I had forgotten about Vadim's compiler.

          Comment


          • #6
            On my previous a10-5800k APU, Vadim's SB compiler was much better than llvm. I tested it a lot.

            Comment


            • #7
              Originally posted by edoantonioco View Post
              Does this means less performance?
              That depends on the hardware I guess. On my card (HD 6950) LLVM causes more stuttering.

              Originally posted by bridgman View Post
              My recollection was that Vadim's "sb" option was running at about the same speed as llvm, and I believe it was enabled by default.
              But Vadim's "sb" option can be enabled with LLVM, too. IIRC it's a shader optimization that happens after the shader has been compiled.

              Comment


              • #8
                Does this also mean that r600 will never get FOSS OpenCL ?? (when and if ready)

                Comment


                • #9
                  " --enable-r600-llvm-compiler [...] but now not even that will disable the compiler back-end by default for this driver." IMHO it should say enable not disable otherwise I fail to find logical conclusion from that statement.

                  Comment


                  • #10
                    Originally posted by 89c51 View Post
                    Does this also mean that r600 will never get FOSS OpenCL ?? (when and if ready)
                    No, it just disables the LLVM backend for the shader compiler. OpenCL is a different thing.

                    Originally posted by ryszardzonk View Post
                    " --enable-r600-llvm-compiler [...] but now not even that will disable the compiler back-end by default for this driver." IMHO it should say enable not disable otherwise I fail to find logical conclusion from that statement.
                    The statement is correct. If you compile mesa without --enable-r600-llvm-compiler you can't enable it at all. If you compile with --enable-r600-llvm-compiler it is still disabled by default but you're able to enable it with R600_DEBUG=llvm

                    //EDIT: In other words: --enable-r600-llvm-compiler compiles the support in (this is a compile-time switch) while R600_DEBUG=llvm enables it at runtime (it is a runtime switch).
                    Last edited by V10lator; 04-17-2014, 07:18 AM.

                    Comment


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

                      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

                              Working...
                              X