More Old GLSL Code Is Gutted From Mesa 22.2

[phoronix]

Phoronix: More Old GLSL Code Is Gutted From Mesa 22.2

It's not only the Linux kernel that's been seeing some spring cleaning but Mesa developers have also been quite busy on working to remove some old, poorly maintained code from their open-source 3D driver components...

https://www.phoronix.com/scan.php?page=news_item&px=Mesa-GLSL-Unrolling-Delete

[sinepgib]

Any benchmarks planned?

[sravn]

It is very interesting to see all these nice incremental improvements that each brings down the technical debt in the massive mesa codebase.
On top of this, work is ongoing to move svga and r600 to the nir compiler - so in the end very few uses a tgsi compiler.
Seeing how the optimizations are moved to nir one-by-one is like sweet music. The line-of-code reduction is maybe not much, but knowing that the drivers move to more well-maintained code is very nice.

[c117152]

Any benchmarks planned?

I believe loop unrolling is done during the intermediate representation (spirv) for shader compilation so it's very unlikely the folks developing the MESA GLSL compilers would make a mistake at that level.

[ehansin]

It is very interesting to see all these nice incremental improvements that each brings down the technical debt in the massive mesa codebase.
On top of this, work is ongoing to move svga and r600 to the nir compiler - so in the end very few uses a tgsi compiler.
Seeing how the optimizations are moved to nir one-by-one is like sweet music. The line-of-code reduction is maybe not much, but knowing that the drivers move to more well-maintained code is very nice.

I thought about this before reading the comments, but I was thinking somewhat along the lines of the above but in more general terms. I am not a coder or expert (though do know some!), but I like reading up on this sort of thing. I like seeing these consistent improvements to core components of the larger ecosystem (Got Kaizen?) To me it means a more solid (and simplified) base to build upon, and I assume (as alluded to above) a more "tight" code base moving forward. Something like that

[sinepgib]

I believe loop unrolling is done during the intermediate representation (spirv) for shader compilation so it's very unlikely the folks developing the MESA GLSL compilers would make a mistake at that level.

Well, the article seems to imply the GLSL loop unrolling is inherently slower than the NIR one, so it'd be interesting to see if that improves load times. I'm not assuming mistakes anywhere, don't know where you get that from. Not only that, but it claims there actually were some misuses, as well as some redundancy (both unrolling stages being run). So I think we could see a small improvement.

[c117152]

Well, the article seems to imply the GLSL loop unrolling is inherently slower than the NIR one, so it'd be interesting to see if that improves load times.

NIR IR's is basically GLSL IR in SSA form so once the control flow is the same, the different optimizations (including unrolling) are easier to apply. The only real concern is that the optimized IR will trigger bugs in old backends or maybe fill up the catches if it ends up longer or the like so they made sure to supply both to let users test things out. However, people misunderstood their intentions and were doing weird things (like running both 0_o) so they gave up and killed off the old code entirely.

I'm not assuming mistakes anywhere, don't know where you get that from.

Since you can tell how the loops are still rolled by converting the different IRs to SPIR-V to see if the loops are unrolled, I've assumed the only reason someone would want to profile the results is if they have a concern NIR is mishandling something specific compared to the old GLSL optimizations. It didn't occur to me people are just curious about the metrics. Sorry.