There's A New Libre GPU Effort Building On RISC-V, Rust, LLVM & Vulkan

[-MacNuke-]

I thought of this a while ago. I don't think that we will see any "widely-used" open-source GPU in the near future. There is just no man-power to create and maintain such things. Most projects start somewhere but fail along the line.

I think there are just 2 options:
1. like this project but not as a separate chip: just make a display output (i.e. DisplayPort) and run everything else on the CPU via LLVMpipe and vulkan-cpu. Sure the CPU needs many cores that way.
or
2. ask AMD or Intel to make one of their older GPUs open-source

[GunpowaderGuy]

This inspires me to pursue the carreer of chip designer. i would like to work on utilizying a transport triggered architecture isa for both general purpouse cpus and more specialized systems . Current efforts are dar todo focused on risc

[brent]

True. But that's most of the silicon logic anyhow considering the rest of the cores just do raw compute... no? I mean, there's a reason they insist on keeping the microcode closed and don't care about the rest being out there. I think?

RISC-V CPUs in NVidia GPUs are mostly used for specialized tasks, as far as I know, e.g. video decoding/encoding coprocessors. I'm not sure, but they might also use them for command processors now. The closed-down nature of the firmware/microcode might be due to DRM, among other things.

Anyway, it's completely wrong to think of a GPU just as a bunch of compute cores. That's usually what the marketing focuses on and what matters most for GPGPU applications, but there's much more to it. When it comes to graphics, think of a GPU more as a fixed-function device with some stages in the processing pipeline that are programmable. Indeed that is exactly what it looks like from the graphics APIs point of view, which closely reflect the hardware. Without those crucial fixed-function parts, throughput easily drops by an order of magnitude. That's why Larrabee failed, even though they did include some minimal hardware features for efficient rendering.

That's also why Nvidia right now is performing so much better in many games: they have much more capable fixed-function blocks, especially on the frontend (i.e. geometry processing, rasterization).

[davidbepo]

huh? a cpu based gpu... larrabee comes to mind and that was an utter failure

[c117152]

RISC-V CPUs in NVidia GPUs are mostly used for specialized tasks, as far as I know, e.g. video decoding/encoding coprocessors. I'm not sure, but they might also use them for command processors now. The closed-down nature of the firmware/microcode might be due to DRM, among other things.

Anyway, it's completely wrong to think of a GPU just as a bunch of compute cores. That's usually what the marketing focuses on and what matters most for GPGPU applications, but there's much more to it. When it comes to graphics, think of a GPU more as a fixed-function device with some stages in the processing pipeline that are programmable. Indeed that is exactly what it looks like from the graphics APIs point of view, which closely reflect the hardware. Without those crucial fixed-function parts, throughput easily drops by an order of magnitude. That's why Larrabee failed, even though they did include some minimal hardware features for efficient rendering.

That's also why Nvidia right now is performing so much better in many games: they have much more capable fixed-function blocks, especially on the frontend (i.e. geometry processing, rasterization).

The way I understood it was that the graphics cores nowadays are just optimized RISC-V compute cores and there's all these separate pieces glued in and spread around (possibly literally in the silicon and as extensions in the ISA) for the video decode and whatnot that go through the controller. So, my impression was that, on the silicon, it was all raw RISC-V processing for the most part unless it's something special right up until the recent generation where that denoise ai for ray-tracing was added. e.g., That 2nd doc I've linked says inverse quant transform (h264/HVEC feature) is being done through the controller... So, my impression was that it's all mostly just regular silicon with few exception thrown over the controller like in this case.

Now you're telling me it's more CISCy with all these specialized logic blocks all over... I don't know. Last I looked through nVidia's patent portfolio I haven't seen too many unique designs and those are copyrightable... Meh. I guess I'm just not up to date enough to opinionate on the subject

[Michael]

True. But that's most of the silicon logic anyhow considering the rest of the cores just do raw compute... no? I mean, there's a reason they insist on keeping the microcode closed and don't care about the rest being out there. I think?

Their Falcon/RISC-V control processor AFAIK is just being used to bring-up the GPU itself and some system management type purposes but not actually doing any of the graphics/compute.

https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-RISC-V-Next-Gen-Falcon

[Weasel]

Damn, both RISC-V and Rust in the same title. Dead on announcement.

[cb88]

Their Falcon/RISC-V control processor AFAIK is just being used to bring-up the GPU itself and some system management type purposes but not actually doing any of the graphics/compute.

https://www.phoronix.com/scan.php?pa...ext-Gen-Falcon

Probably the drivers don't even interact with it at all except perhaps for power management type stuff, or negotiating trust of certain things, it's basically doing the same job that the embedded controller does in modern CPUs (ARM Trustzone on AMD / Arc or Sparc others on Intel). It's litereally just an isolated little microcontroller in there that they can program to do menial tasks.

[Michael]

Probably the drivers don't even interact with it at all except perhaps for power management type stuff, or negotiating trust of certain things, it's basically doing the same job that the embedded controller does in modern CPUs (ARM Trustzone on AMD / Arc or Sparc others on Intel). It's litereally just an isolated little microcontroller in there that they can program to do menial tasks.

Yep right that's my expectation of it as well, far from RISC-V NV being anything actually doing any graphics/compute work.

[Weasel]

Probably the drivers don't even interact with it at all except perhaps for power management type stuff, or negotiating trust of certain things, it's basically doing the same job that the embedded controller does in modern CPUs (ARM Trustzone on AMD / Arc or Sparc others on Intel). It's litereally just an isolated little microcontroller in there that they can program to do menial tasks.

Shh now oiaohm will come how Western Digital funds massively in RISC-V for clearly use-cases other than a stupid microcontroller.