Nvidia's CUDA Platform Now Support RISC-V

An anonymous reader quotes a report from Tom's Hardware: At the 2025 RISC-V Summit in China, Nvidia announced that its CUDA software platform will be made compatible with the RISC-V instruction set architecture (ISA) on the CPU side of things. The news was confirmed during a presentation during a RISC-V event. This is a major step in enabling the RISC-V ISA-based CPUs in performance demanding applications. The announcement makes it clear that RISC-V can now serve as the main processor for CUDA-based systems, a role traditionally filled by x86 or Arm cores. While nobody even barely expects RISC-V in hyperscale datacenters any time soon, RISC-V can be used on CUDA-enabled edge devices, such as Nvidia's Jetson modules. However, it looks like Nvidia does indeed expect RISC-V to be in the datacenter.

Nvidia's profile on RISC-V seems to be quite high as the keynote at the RISC-V Summit China was delivered by Frans Sijsterman, who appears to be Vice President of Hardware Engineering at Nvidia. The presentation outlined how CUDA components will now run on RISC-V. A diagram shown at the session illustrated a typical configuration: the GPU handles parallel workloads, while a RISC-V CPU executes CUDA system drivers, application logic, and the operating system. This setup enables the CPU to orchestrate GPU computations fully within the CUDA environment. Given Nvidia's current focus, the workloads must be AI-related, yet the company did not confirm this. However, there is more.

Also featured in the diagram was a DPU handling networking tasks, rounding out a system consisting of GPU compute, CPU orchestration, and data movement. This configuration clearly suggests Nvidia's vision to build heterogeneous compute platforms where RISC-V CPU can be central to managing workloads while Nvidia's GPUs, DPUs, and networking chips handle the rest. Yet again, there is more. Even with this low-profile announcement, Nvidia essentially bridges proprietary CUDA stack to an open architecture, one that seems to develop fast in China. Yet, being unable to ship flagship GB200 and GB300 offerings to China, the company has to find ways to keep its CUDA thriving.

RISC is Good

[OrangeTide]

Showing my age, but obligatory clip [youtube.com].

"Central" is probably overstating it.

[fuzzyfuzzyfungus]

It's definitely interesting that Nvidia thinks RISC-V is big enough to be worth the port; but describing the CPU as 'central' to Nvidia's preferred design is deeply overselling it. The recommended layout is basically a bunch of GPUs chatting with one another over NVLink within the chassis; and using GPUDirect RDMA on Nvidia infiniband cards located on the same PCIe switch that the GPUs are for scaleout; with Nvidia ethernet DPUs handling the remaining high speed networking; and the CPU doing housekeeping.

Re:

[drinkypoo]

Nvidia wants to free themselves from being dependent on anyone else for their big systems. You still need a CPU to run the OS. This way they can own it top to bottom.

Re:

[DamnOregonian]

I think this would probably definitely be their end-goal. I suspect AMD would like to do the same thing.
99.9% of all difficulty working with the big crunchers is OS+driver bullshit.

If I were them, I'd be looking to make a product where you're really just talking to a combined system via a mailbox with a defined API, rather than trying to deal with the nightmare of virtual memory management across 8 GPUs.

Re:

[arglebargle_xiv]

Could also just be them making sure they don't get left out. This is why big orgs publicly sign up for every standards group and industry initiative that exists, they don't believe in many of them but also don't want to get left out.

Re:

[DamnOregonian]

Ehhh, the GPUs don't particularly "chat with one another".
You're right that they have direct communications- but there's no real way to program them to utilize them.
For example, you've got a network layer spread across 5 GPUs- the FMAs can be done on all of them, but the product needs to be combined. You can't program your kernel to do this- it has no way to communicate with the other cards. So the commands to the GPU to send the data over the appropriate pipes to a combining kernel and then redist must c