Even as an ML-focused graphics-less GPU, this is great. If this can be prototyped on an FPGA, it would be even better. Using block RAM for shared memory and built-in PCIe and DDR IP blocks should help speed things up considerably.
It unfortunately wouldn't be very cost-effective for training ML models, but it would take things a step closer to actual tape-out (if some organization has the $$$ for it).
Worth noting this is targeting ML applications, so I don't think you'll be able to display even a text console with it for the foreseeable future.
But I love that this is even in the realm of possibilities! There's no reason we couldn't, in principle, have a small open-source GPU taping out on the free Skywater shuttle, and I am here for it!
I feel like the name’s been funny for a decade and a half, and a new name might be coming, but GPU has been pretty synonymous with massively parallel vector/SIMD processor for a long time, right? Most still have some dedicated graphics functionality, but people have also been using them for high performance headless compute for quite a while. I certainly prefer just GPU over GPGPU. It seems hard to change though, and might be confusing to call it a vector processor, considering CPUs have vector/SIMD support. So what would be a better name?
Well there are definitely cases where you want to render frames and not view them in real time. For example, rendering the final cut of an animated movie.
We work on an open source tensor processing unit at https://tensil.ai. It is not RISC-V based since only a handful of very simple instructions is needed for expressing data flows typical in ML.
Here's what looks like one meant for actual video output, from over a decade ago and I'm not sure if the project made much progress either: https://news.ycombinator.com/item?id=19724986
> Internal GPU Core ISA loosely compliant with RISC-V ISA. Where RISC-V conflicts with designing for a GPU setting, we break with RISC-V.
Very amateur question: I thought RISC-V added vector extensions so you could use it directly for GPU/TPU chips without having to fragment the ecosystem?
The V extension is more akin to the various SIMD extensions of x86 (SSE/AVX) or ARM (NEON) than a GPU system. I’m sure one could make a GPU based on RV-V, but the extension is more GPGPU like than a pixel/shader pipeline.
Neat! Looks like it's very much in its early stages (no concurrent execution/threads yet) but it's so great to see FOSS digital design work in an industry dominated by huge players
I'm not really optimistic about the hardware and the tape-out goal. The author seems to have a very basic knowledge about it.
For instance, the int multiplier design is overengineered, very naive and far from state of the art (no pipeline, no adder compressor). I would suggest the author to check wallace tree multiplier.
But at this stage it would be preferable to use the native verilog multiply or a DSP macro to target FPGA for prototyping, and to focus the SIMT architecture and the pipelining. Arithmetic unit design is a science in its own.
I'm interested whether it would be a good idea to implement a Vulkan driver for such GPU via emulating TMUs and ROPs in software, and it might not even matter that much since modern rendering pipelines are more and more compute reliant anyways(UE5 Nanite barely uses hardware rasterizers, latest idTech uses software rasterization as well). The only problem I see lies is with raytracing since it is pretty reliant on fixed function units.
You mean that the latest idTech engine is not using the fixed-function 3D pipeline at all, namely full compute (no vertex/fragment shaders)? Still using the texture sampling units?
No, it still uses triangles. That seems to be a misunderstanding of how they do their clusters: They switched to a software rasterizer for drawing light volumes and decals into the clustered light buffer, meaning it's now a scatter rather than a gather (parallelized over lights, rather than tiles). This is pretty standard, but it's limited to those low res cluster info buffers, and is only rasterizing a handful of triangles per light.
It unfortunately wouldn't be very cost-effective for training ML models, but it would take things a step closer to actual tape-out (if some organization has the $$$ for it).