Announcement

Collapse
No announcement yet.

Mesa's Loop Analysis & Range Propagation Passes

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

  • Mesa's Loop Analysis & Range Propagation Passes

    Phoronix: Mesa's Loop Analysis & Range Propagation Passes

    Besides the atomic mode-setting for virtual KMS drivers, another X.Org Google Summer of Code project this summer was developing a range analysis pass and other optimization passes for Mesa as part of benefiting NIR...

    http://www.phoronix.com/scan.php?pag...ange-GSoC-2015

  • #2
    If there's any questions; fire at will, and I'll try to give a decent answer.

    Comment


    • #3
      Okay, here is one just for start: What this work will give to Mesa? Do we expect some performance improvement of the shaders, etc?

      Comment


      • #4
        Why NIR? Why not LLVM IR which already has plenty of passes? Is it less work to reinvent the wheel, if yes, why?

        And using LLVM IR might be better for the future as well. For example there were some tools proposed to convert between LLVM IR and Vulkan IR.

        Comment


        • #5
          Originally posted by Drago View Post
          Okay, here is one just for start: What this work will give to Mesa? Do we expect some performance improvement of the shaders, etc?
          Eventually it should be good for shader performance, yes (the value range propagation that is). For now it does not give noticeable advantage for i965, as that hardware has a lot of source modifiers for it's instructions that are free of charge on execution, and these are the instructions that happens to get eliminated at the moment. I expect vc4 and freedreno to benefit more, as these does not have the same amount of fancy source modifiers, but I haven't checked that yet. The VRP pass should for example figure out that max(sin(x), 6) will always become 6, and replace with a constant, or find that the abs in abs(exp(x)) is unnecessary as exp(x) is always positive.

          The LCSSA and loop analysis passes are passes that are necessary to implement loop unrolling, loop invariant code motion, loop in switching, +++. These are things that we will benefit from when we start using the information the analysis gathers, as shaders with loops should get optimized better, leading to better performance.

          There are also multiple other ways the information gathered by these passes can be utilized that has been discussed, but not implemented. It will certainly be interesting to see what we can get out of it, once we find a good way to integrate it.

          Comment


          • #6
            Originally posted by xazax View Post
            Why NIR? Why not LLVM IR which already has plenty of passes? Is it less work to reinvent the wheel, if yes, why?

            And using LLVM IR might be better for the future as well. For example there were some tools proposed to convert between LLVM IR and Vulkan IR.
            I'd assume LLVM already has a loop analysis pass and other advanced passes. And I'm sure the point of doing this was to support the Intel driver, which doesn't use LLVM.

            Comment


            • #7
              Originally posted by smitty3268 View Post

              I'd assume LLVM already has a loop analysis pass and other advanced passes. And I'm sure the point of doing this was to support the Intel driver, which doesn't use LLVM.
              Sure, I am aware of that. My main question is, what is the reason that the Intel guys do not want to jump in the LLVM train.

              Comment


              • #8
                Originally posted by xazax View Post
                Why NIR? Why not LLVM IR which already has plenty of passes? Is it less work to reinvent the wheel, if yes, why?

                And using LLVM IR might be better for the future as well. For example there were some tools proposed to convert between LLVM IR and Vulkan IR.
                If you want a thorough explanation as to why NIR instead of LLVM I suggest you look up the phoronix article about NIR getting merged. I remember Connor, the guy who wrote the initial NIR-code giving some quite thorough explanations. Don't have the link at hand atm, but should be simple enough to search for. I don't want another LLVM bikeshed-flamewar on here, as that leads us nowhere.

                LLVM already has all of this stuff, in one way or another, so there's no reason to write such a pass for LLVM.

                There are currently three drivers using NIR as default; i965, vc4, and freedreno. LLVM is used as default only by radeonsi (and llvmpipe). So my work benefits three drivers instead of, in practice, none(since LLVM has this already). NIR is the ir in mesa where things are happening atm, and I want my work to benefit more than just one driver. And the guys who mentored me, and suggested I apply, are all deeply invested in NIR. That kinda settles it for me. I don't expect there to be wide support in Mesa for LLVM ir, and having an in-house ir instead is nice as there are no external dependencies.

                Did that answer your questions?

                Comment


                • #9
                  you mean you would have been basically unemployed if "mesa" as you say or rather the intel driver switched to llvm...?

                  Comment


                  • #10
                    Originally posted by helland View Post

                    If you want a thorough explanation as to why NIR instead of LLVM I suggest you look up the phoronix article about NIR getting merged. I remember Connor, the guy who wrote the initial NIR-code giving some quite thorough explanations. Don't have the link at hand atm, but should be simple enough to search for. I don't want another LLVM bikeshed-flamewar on here, as that leads us nowhere.

                    LLVM already has all of this stuff, in one way or another, so there's no reason to write such a pass for LLVM.

                    There are currently three drivers using NIR as default; i965, vc4, and freedreno. LLVM is used as default only by radeonsi (and llvmpipe). So my work benefits three drivers instead of, in practice, none(since LLVM has this already). NIR is the ir in mesa where things are happening atm, and I want my work to benefit more than just one driver. And the guys who mentored me, and suggested I apply, are all deeply invested in NIR. That kinda settles it for me. I don't expect there to be wide support in Mesa for LLVM ir, and having an in-house ir instead is nice as there are no external dependencies.

                    Did that answer your questions?
                    It is a bit surprising to me that Intel guys choose to redo everything from scratch. LLVM is already a dependency for Mesa due to radeonsi. I will search and check that article, thank you for the suggestion. Hopefully that will answer my question.

                    Comment

                    Working...
                    X