VeriGPU: GPU in Verilog loosely based on RISC-V ISA | Hacker News Reader

VeriGPU: GPU in Verilog loosely based on RISC-V ISA

github.com

101 pointsbtdmaster23 comments

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!

It's funny that we've gotten to the point that a "graphics-less GPU" is actually useful. Perhaps they should call it something else...

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?

GPUs without graphics support are already a thing. But so far, NVIDIA is staying on the GPU term.

For the H100, very minimalistic FF support was picked.

Only two TPCs in both the SXM5 and PCIe H100 GPUs are graphics-capable (that is, they can run vertex, geometry, and pixel shaders). And that’s out of:

8 GPCs, 66 TPCs, 2 SMs/TPC, 132 SMs per GPU

for an H100 SXM5.

Aka just for compatibility.

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.

It's only a matter of time before GPU gets backronym-ed to General Processing Unit or something similarly wacky.

Like a “tensor processing unit” or TPU?

A RISC-V open source TPU would be a big innovation in AI and scientific computing.

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.

GPPU

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

Perhaps also see the (OpenPOWER-based) Libre-SOC effort https://libre-soc.org/

> 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.

However it's a beautiful project!

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.

Every 10 years, someone will reinvent Larabee.

hu?

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.

From the planning document:

> Branching: Done

> Single instruction multiple thread (SIMT): Planned

I guess we should be supportive, and it is impressive how far they got on the software side, but boy, is the author in for a surprise.

Very cool, but can someone remind me what "GPU" means again?

Generic Processing Unit, it seems.

Reply on news.ycombinator.com