The Difference In Optimizations Between NIR & GLSL

[Michael]

@Michael : (pow, 4) isn (x*x)*(x*x). What you wrote in the article "(x*x)*x(x*x)." is (pow,5).

Just a typo, will fix it. Thanks.

[efikkan]

While this might be "just one line", that's not the same as just one instruction.

[toyotabedzrock]

(x*x)*(x*x) is not as efficient as it could be. It would be better to do
y = x*x
y = y*y
Either way it has to make two trips threw the GPU but the second way uses fewer registers and compute resources.

[cwabbott]

(x*x)*(x*x) is not as efficient as it could be. It would be better to do
y = x*x
y = y*y
Either way it has to make two trips threw the GPU but the second way uses fewer registers and compute resources.

We have a CSE pass in NIR that transforms the former into the latter.

Also, it would have definitely been possible to have the GLSL pass be on one line... we just didn't bother porting the Python framework that autogenerates these optimizations to GLSL IR. The real significance is that the NIR version will catch cases where the GLSL IR one wouldn't, thanks to SSA.

[cwabbott]

Yeah, they aren't.

I mean, you could say that TGSI is like a serialized form of NIR, and that would be sort of correct on an abstract level. But practically they aren't the same at all, and neither is SPIR-V.

No, they're actually rather similar, or at least the graphics-oriented subset of SPIR-V is. They're both SSA-based, have native support for graphics things like texturing, and do I/O through reading/writing variables. Please tell me how they're different.

[vadix]

Its not definitive yet whether Vulkan will fully supplant OpenGL. Vulkan may end up being used when maximum performance is necessary, and OpenGL being used whenever its not performance-critical. It takes a lot to get Vulkan up off of the ground for a program. Rendering a triangle in OpenGL was something like 60 lines of code, with Vulkan being 600 or so.

Although I see where you are coming from, wrapper libraries can probably offer the basic functionality. Opengl doesnt have those because opengl 2 and before contained the simple drawing routines, but vulkan doesnt, so people will probably make drawing libraries.

[smitty3268]

No, they're actually rather similar, or at least the graphics-oriented subset of SPIR-V is. They're both SSA-based, have native support for graphics things like texturing, and do I/O through reading/writing variables. Please tell me how they're different.

I agree that if you are arguing they are abstractly similar, then sure, in the same way any serialization format would be similar to an in-memory IR. But you could say the same thing about TGSI (if it had an extra pass to turn it into SSA form, something that was discussed in the past, for example).

The purposes of SPIR-V and NIR are completely different. COMPLETELY different. And I think it was very clear that the original poster here didn't understand that and was trying to draw some kind of direct line between the two that doesn't exist. NIR was not created based on SPIR-V specs. SPIR-V wasn't created based on NIR specs. The two are just similar because they both try to expose what GPU hardware can do.

[cwabbott]

I agree that if you are arguing they are abstractly similar, then sure, in the same way any serialization format would be similar to an in-memory IR. But you could say the same thing about TGSI (if it had an extra pass to turn it into SSA form, something that was discussed in the past, for example).

Actually, they're not nearly as similar. Aside from not supporting SSA, TGSI is also completely typeless and turns everything into a single flat array of virtual registers, when SPIR-V doesn't do this -- NIR also has registers, but they're meant to be used at the very end to help the driver optimize index expressions (and avoid having the backend deal with variables directly).

The purposes of SPIR-V and NIR are completely different. COMPLETELY different. And I think it was very clear that the original poster here didn't understand that and was trying to draw some kind of direct line between the two that doesn't exist. NIR was not created based on SPIR-V specs. SPIR-V wasn't created based on NIR specs. The two are just similar because they both try to expose what GPU hardware can do.

Right, they weren't created by the same people, they aren't based on one another, and one is a serialized format whereas another is designed for actual optimizations... but besides those differences, the philosophy is pretty similar. Probably since they're both SSA-based and try to keep around the high-level information that different drivers need to be able to optimize effectively for their architectures. In other words, a NIR -> SPIR-V -> NIR translation wouldn't lose too much information, as compared to NIR -> TGSI -> NIR for example.

[smitty3268]

See, we are clearly looking at this from 2 very different angles. Because when i look at

Aside from not supporting SSA, TGSI is also completely typeless and turns everything into a single flat array of virtual registers, when SPIR-V doesn't do this -- NIR also has registers, but they're meant to be used at the very end to help the driver optimize index expressions (and avoid having the backend deal with variables directly).

I see little implementation details.

Then i look at

Right, they weren't created by the same people, they aren't based on one another, and one is a serialized format whereas another is designed for actual optimizations...

and see giant gaping differences in contrast to the above.

You obviously wrote a lot of those implementation details in NIR which i think is why you are focusing on them. I suppose both are valid, they are just different ways of looking at the same information.