<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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.</div></blockquote><div><br></div><div>That is the thing: there is already a community maintained LLVM backend for RISC-V and I need to see how to get value from that effort. And that is a very typical escenario for new architectures. There is already an LLVM backend for a programmable device and someone asks: could you do some graphics around this without spending millions?</div><div><br></div><div>Then your options as an engineer are:<br></div><div><br></div><div>- Use Mesa as a framework and translate NIR to assembly (most likely choice).</div><div><br></div><div>- Use Mesa as a framework and translate NIR to LLVM IR with some intrinsics, then feed the pre-existing LLVM backend.<br></div><div><br></div><div>- Use some new alternative, possibly a Mesa fork relying on the Khronos SPIR-V to LLVM IR translator. Start fixing the tool for supporting graphics... Make SPIR-V the IR that communicates frontend and backend :-)<br></div><div><br></div><div>I am not thinking in terms of what is best for Mesa, but in terms of how could the RISC-V community organize its effort given that an LLVM backend is a given thing.</div><div><br></div><div>I see the current reasons why NIR is preferred over SPIR-V in Mesa. So far you have given me three<br></div><div><br></div><div>- There is a well designed library for traversing NIR, whereas SPIR-V defines nothing.<br></div><div>- The arrays and structs are lowered before the shader is passed to the backend.</div><div>- You see SPIR-V as a "serializing" format for IR to be exchanged through the network (like a .PNG for shaders), whereas NIR's focus is more about how the data structures are represented in memory while in use.<br></div><div><br></div><div>My takeaway messages are two:</div><div><br></div><div>- Advise to support NIR on the RISC-V plan.<br></div><div>- If I have a chance, suggest to Khronos making SPIR-V more like NIR, so in the future it is considered beyond a serializing format.</div><div><br></div><div>Thanks for your comments so far.<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 21, 2022 at 4:24 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 dir="ltr">On Thu, Jan 20, 2022 at 5:49 PM Abel Bernabeu <<a href="mailto:abel.bernabeu@esperantotech.com" target="_blank">abel.bernabeu@esperantotech.com</a>> wrote:<br></div><div class="gmail_quote"><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>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.</div></div></blockquote><div><br></div><div>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.</div><div> </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>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.</div></div></blockquote><div><br></div><div>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.</div><div> </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>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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>--Jason</div><div><br></div><div> </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>- 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> </blockquote></div></div> </blockquote></div>