<div dir="ltr"><div>Dave,</div><div><br></div><div>Am glad for the Mesa community to support the RISC-V effort with the advice given so far.</div><div><br></div><div>I hear your concerns regarding performance. I am familiar with the Larabee case and know some of the people who worked on that. However, I am not here to discuss what is the RISC-V strategy for graphics beyond the fact that there is a NIR backend planned. That would be offtopic for this list.<br></div><div><br></div><div>Join the Graphics and ML SIG at RISC-V and let us discuss it there.</div><div><br></div><div>First join RISC-V as an individual contributor, strategic member or community member:<br></div><div><a href="https://riscv.org/membership/" target="_blank">https://riscv.org/membership/<br><br></a></div><div>Then join the Graphics and ML SIG through the Working Groups Portal. Feel free to ask for details privately.</div><div><br></div><div>Thanks.<br></div><div><a href="https://riscv.org/membership/" target="_blank"></a></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 23, 2022 at 9:10 PM Dave Airlie <<a href="mailto:airlied@gmail.com" target="_blank">airlied@gmail.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">On Sun, 23 Jan 2022 at 22:58, Abel Bernabeu<br>
<<a href="mailto:abel.bernabeu@esperantotech.com" target="_blank">abel.bernabeu@esperantotech.com</a>> wrote:<br>
>><br>
>> 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.<br>
><br>
><br>
> 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?<br>
<br>
No.<br>
<br>
If you want something useful, it's going to cost millions over the<br>
lifetime of creating it. This stuff is hard, it needs engineers who<br>
understand it and they usually have to be paid.<br>
<br>
RISC-V as-is isn't going to make a good compute core for a GPU. I<br>
don't think any of the implementations are the right design. as long<br>
as people get sucked into thinking it might, there'll be millions<br>
wasted. SIMT vs SIMD is just making SSE-512 type decisions or<br>
recreating Intel Larrabee efforts. Nobody has made an effective GPU in<br>
this fashion. You'd need someone to create a new GPU with it's own<br>
instruction set (maybe dervied from RISC-V), but with it's own<br>
specialised compute core.<br>
<br>
The alternate more tractable project is to possibly make sw rendering<br>
(with llvmpipe) on RISC-V more palatable, but that's really just<br>
optimising llvmpipe and the LLVM backend and maybe finding a few<br>
instructions to enhance things. It might be possible to use a texture<br>
unit to speed things up and really for software rendering and hw<br>
rendering, memory bandwidth is a lot of the problem to solve.<br>
<br>
Dave.<br>
</blockquote></div>