Replacing NIR with SPIR-V?

[Jason Ekstrand]

On Thu, Jan 20, 2022 at 5:49 PM Abel Bernabeu <
abel.bernabeu at esperantotech.com> wrote:

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

First off, that blog post is truly ancient.  Based on the quote from
nir_opt_algebraic.c, it looks like less than 6 months after the original
NIR patches landed which puts it at 5-6 years old.  A lot has changed since
then.


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

In terms of what they're capable of communicating, yes, SPIR-V and NIR can
express many of the same things.  But that's not the point.  The point is
that there's a lot that happens between coming out of GLSL or SPIR-V and
going into the back-end.  A lot of what we do with NIR is share as much of
that lowering across drivers as possible.  Yes, we could convert back to
SPIR-V before going into back-ends but there's really no point since they
need their own IRs anyway.  If you're dumping straight into LLVM or
similar, then maybe you don't need any of that, but if you're building a
custom back-end, you really want to let NIR do that lowering and you don't
want to handle it all on your own.


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

A big part of the point of NIR is to get rid of these things so that
drivers don't have to deal with them.  Yes, NIR arrays and struct and
nir_deref to deal with them but, by the time you get into the back-end, all
the nir_derefs are gone and you're left with load/store messages with
actual addresses (either a 64-bit memory address or a index+offset pair for
a bound resource).  Again, unless you're going to dump straight into LLVM,
you really don't want to handle that in your back-end unless you really
have to.

Over-all, I think you're asking the wrong set of questions.  If you're
trying to understand Mesa GPU compilers, looking at NIR from documentation
and blog posts and comparing with SPIR-V is likely to raise more questions
than answers.  I would instead recommend looking at an actual driver and
seeing how things flow through the compiler stack.  That's likely to teach
you a lot more about how the Mesa compiler stack works than reading blogs.
That, or start implementing a NIR back-end and see what you run into and
ask questions on #dri-devel.

--Jason



> - 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/20220120/e63546d8/attachment-0001.htm>