Mesa's Loop Analysis & Range Propagation Passes

[helland]

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).

[helland]

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.

[xazax]

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.

[xazax]

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.

[jakubo]

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

[helland]

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?

[xazax]

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.

[smitty3268]

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.

[helland]

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.

[xazax]

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.