<div dir="ltr"><div>I can tease you all with the promise of SIMT and fixed function units.</div><div><br></div><div>In the meantime you can hear me talking about the work we do at the Graphics and ML Special Interest Group within RISC-V:<br></div><div><a href="https://www.youtube.com/watch?v=kM0lsWjqOaw">https://www.youtube.com/watch?v=kM0lsWjqOaw</a></div><div><br></div><div>I still need to make our site a bit more useful, but here is the GitHub repo where I put our meeting minutes:</div><div><a href="https://github.com/riscv-admin/graphics">https://github.com/riscv-admin/graphics</a></div><div><br></div><div>Regards.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 23, 2022 at 11:07 PM Ian Romanick <<a href="mailto:idr@paranormal-entertainment.com" target="_blank">idr@paranormal-entertainment.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 1/23/22 12:10 PM, Dave Airlie wrote:<br>
> 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>
For the love of all that is good in the world, no! :) That was my <br>
original master's project that I gave up on.<br>
<br>
Executive summary: There's a reason GPUs have huge piles of <br>
fixed-function blocks.  It's the only way to get enough power <br>
efficiency, and power consumption (and the heat it generates) is *the* <br>
problem.<br>
<br>
> Dave.<br>
<br>
</blockquote></div>