<div dir="ltr"><div>In principle, all the properties you highlight in your <a href="https://www.jlekstrand.net/jason/projects/mesa/nir-notes/" target="_blank">blog</a> 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.<br></div><div><br></div><div>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 :-)</div><div><br></div><div>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:<br></div><div><br></div><div>- 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.<br></div><div><br></div><div>- 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.<br></div><div><br></div><div>Regards.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 20, 2022 at 2:36 AM Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>> - Does it make sense to move to SPIR-V?</div><div><br></div><div>None whatsoever. SPIR-V is an interchange format, not a set of manipulatable data structures suitable for compiler lowering and optimization.</div><div><br></div><div>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.</div><div><br></div><div>--Jason<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 19, 2022 at 7:17 PM Abel Bernabeu <<a href="mailto:abel.bernabeu@esperantotech.com" target="_blank">abel.bernabeu@esperantotech.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>My name Abel Bernabeu and I currently chair the Graphics and ML Special Interest Group within RISC-V.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>- My understanding is that when mesa adopted NIR, there was no SPIR-V. Was a comparison made after the SPIR-V ratification?</div><div><br></div><div>- Does it make sense to move to SPIR-V?</div><div><br></div><div>- Is it feasible in terms of functionality supported by SPIR-V?</div><div><br></div><div>- Is the cost worth the potential advantage of using a more commonly adopted standard?</div><div><br></div><div>Thanks in advance for your time and thoughts.<br></div><div><br></div><div>Regards.<br></div></div> </blockquote></div> </blockquote></div>