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 <ja...@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.berna...@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. >> >
