Replacing NIR with SPIR-V?

Abel Bernabeu abel.bernabeu at
Thu Jan 20 23:48:48 UTC 2022

In principle, all the properties you highlight in your blog
<> as key points
of NIR also apply to SPIR-V. I was curious to know where in the details
that I miss, NIR starts shining as a more suitable IR than SPIR-V for the
task of communicating front-end and back-end. By the way, thanks for
putting together that blog post.

As it seems clear that the NIR question is well settled within the mesa
community and I really see value in having mesa drivers, I promise to pay
as much attention to the NIR use cases as I did with SPIR-V :-)

By the way, we are not planning on supporting with specific RISC-V
instructions everything that has an instruction on SPIR-V. Regarding the
two areas you mention:

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

- Trigonometric operations: personally I consider that only "sin" and "cos"
are needed additions for RISC-V. Unclear what precision yet, likely 8 bits,
for serving as initial value for a Newton-Rapson style computation.


On Thu, Jan 20, 2022 at 2:36 AM Jason Ekstrand <jason at> wrote:

> > - Does it make sense to move to SPIR-V?
> None whatsoever.  SPIR-V is an interchange format, not a set of
> manipulatable data structures suitable for compiler lowering and
> optimization.
> You also don't want to build hardware around consuming SPIR-V.  There are
> lots of things that the SPIR-V has which you wouldn't want to support
> natively in hardware such as structures and arrays in SSA values or complex
> trig ops like atan2().  Part of the purpose of NIR is to lower these things
> to simpler constructs which are supported in native hardware.
> --Jason
> On Wed, Jan 19, 2022 at 7:17 PM Abel Bernabeu <
> abel.bernabeu at> wrote:
>> Hi,
>> My name Abel Bernabeu and I currently chair the Graphics and ML Special
>> Interest Group within RISC-V.
>> As part of my work for RISC-V I am currently looking at what is needed
>> for supporting a graphics product that uses a (potentially extended) RISC-V
>> ISA for its shading cores. My initial focus has been on analyzing the
>> functional gap between RISC-V and SPIR-V, assuming that whatever is needed
>> for a modern graphics accelerator is inevitably present on SPIR-V.
>> Now, the thing is that most of the potential adopters on our committee
>> will likely be interested in using mesa for developing their drivers and
>> that means using NIR as intermediate representation. Thus, I also need to
>> consider NIR when looking at the functional gap, doubling the amount of
>> work during the analysis.
>> Why is mesa using NIR as intermediate representation rather than SPIR-V?
>> It would make my life easier if mesa used SPIR-V rather than NIR for
>> communicating the front-end and the backends.
>> I know it is a lot of work to migrate to SPIR-V, but I am interested in
>> knowing what is the opinion of the mesa developers:
>> - My understanding is that when mesa adopted NIR, there was no SPIR-V.
>> Was a comparison made after the SPIR-V ratification?
>> - Does it make sense to move to SPIR-V?
>> - Is it feasible in terms of functionality supported by SPIR-V?
>> - Is the cost worth the potential advantage of using a more commonly
>> adopted standard?
>> Thanks in advance for your time and thoughts.
>> Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the mesa-dev mailing list