Announcement

Collapse
No announcement yet.

Mesa's Loop Analysis & Range Propagation Passes

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

  • phoronix
    started a topic Mesa's Loop Analysis & Range Propagation Passes

    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

  • helland
    replied
    Originally posted by xazax View Post

    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.
    LLVM is a dependency that not everyone is happy about. I'm personally very pleased with owning only r600, i965, and freedreno hardware. With careful compilation there's no dependency nightmares. And it's really nice (at least that's my opinion) to have everything in one place. Makes it simple to follow the flow of input-data all the way to the hardware, and simple to program.

    Also, LLVM is not a perfect match for GPU's. So NIR has some concepts, like swizzle and writemasks, etc, that are not standard LLVM. That's also probably the reason why spir-v / vulkan diverged from LLVM (I believe the initial design was based on LLVM ir, but I might be mistaking).

    Leave a comment:


  • helland
    replied
    Originally posted by jakubo View Post
    you mean you would have been basically unemployed if "mesa" as you say or rather the intel driver switched to llvm...?
    If that was the case then I'd have to find something else to do instead. As it was, I've mostly been hacking on the compiler parts inside Mesa, as that has been what has interested me, matched my hardware, and given the most benefit for me. When i was applying for gsoc it made a lot of sense to work in the same area, but step it up a notch to more advanced compiler paspasses instead of just small additions and cleanups. I'm not employed by any means, just doing it as a spare time activity to expand my horizons, so I wouldn't be "unemployed ". But if all the drivers used LLVM there's still a boatload of stuff to do, so I would always find something.

    Leave a comment:


  • xazax
    replied
    Sorry for the double post, but I have one more question.

    Why is the NIR typeless? What is the benefit of that? Having types could be useful for optimizations such as type based alias analysis.

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • helland
    replied
    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?

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:

Working...
X