Announcement

Collapse
No announcement yet.

Mesa's Loop Analysis & Range Propagation Passes

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

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

    Comment


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

      Comment


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

        Comment

        Working...
        X