Replacing NIR with SPIR-V?

[Abel Bernabeu]

In principle, all the properties you highlight in your blog
<https://www.jlekstrand.net/jason/projects/mesa/nir-notes/> 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.

Regards.

On Thu, Jan 20, 2022 at 2:36 AM Jason Ekstrand <jason at jlekstrand.net> 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 esperantotech.com> 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: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20220121/ec0a7843/attachment.htm>