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