If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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

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:

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:

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:

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.

Leave a comment:

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.