Replacing NIR with SPIR-V?

[Alyssa Rosenzweig]

>    In principle, all the properties you highlight in your blog as key points
>    of NIR also apply to SPIR-V.

Those key points are relative to GLSL IR, the IR it displaces. The
purpose of SPIR-V is so different than both NIR and GLSL IR it isn't
interesting to do a comparison. Comparing with LLVM IR would be more
appropriate. (The relationship between SPIR-V and LLVM IR
notwithstanding)

>    NIR starts shining as a more suitable IR than SPIR-V for the
>    task of communicating front-end and back-end

That is not the goal of NIR. The frontend can pass SPIR-V if it is so
inclined, that's a single spirv_to_nir pass a way, and that's how the
OpenGL extension and Vulkan SPIR-V works.

As for backends, it makes 0 sense whatsoever for any backend in all of
Mesa to consume SPIR-V. That's not what SPIR-V is for.

>    - Arrays and structs: SPIR-V's OpAccessChain would need to be processed by
>    a backend and translated to pointer arithmetic plus dereferencing (kind of
>    the same thing as having to process a nir_deref). This translation can be
>    done in RISC-V with no issue, whether it is OpAccessChain or nir_deref.

NIR does that translation for you if you tell it to.