CUDA Is Coming to RISC-V, But Only for Server-Grade Silicon

At Hot Chips 2026, Nvidia laid out its plan to bring CUDA to RISC-V CPUs. The move is significant: CUDA has been locked to x86-64 and aarch64 for years, and RISC-V has been knocking on the server door without a software ecosystem to back it. Nvidia's requirements, however, make it clear this is not about hobbyist boards. They want server-grade silicon, and they want it to meet a specific set of standards.

First, Nvidia requires an RVA23 CPU, plus adherence to the RISC-V server SoC and server platform specifications. Those specs cover RAS features, a security processor, and other baseline enterprise expectations. That alone filters out most of the RISC-V hardware shipping today.

Beyond the profile, Nvidia wants a few things that aren't guaranteed by the specs. Vector extensions are one example: Nvidia wants predication support to avoid branches in CUDA kernels. They explicitly don't want a lowest-common-denominator situation where they can't use performance-enhancing extensions because some hardware might not have them. That would force them to ship inefficient code.

ACPI is another sticking point. Nvidia's software team wasn't happy when they started porting CUDA because RISC-V lacked ACPI. That's since been resolved: the UEFI forum added RISC-V ACPI support in 2025, and the RISC-V BRS spec includes it. But adoption will take time, as the aarch64 world has shown—ACPI support there has been spotty despite being in standards for years.

Then there's PCIe coherency. Nvidia wants a guarantee, not a recommendation. Without it, DMA engines can read stale data from DRAM while modified data sits in CPU caches, and the CPU can read stale data after DMA writes. Software would have to explicitly invalidate caches, which is a nightmare to work into the CUDA stack. Nvidia considers coherency a standard server CPU feature, and the RISC-V server SoC spec only recommends it. Nvidia wants it mandatory.

Peer-to-peer PCIe communication is also required. Without it, buffers copied between two devices have to go through CPU memory, which costs performance and adds synchronization complexity.

Nvidia didn't go through every requirement in detail—they noted the full list fits within two pages. But the gist is clear: this is enterprise-grade territory.

NVLink Fusion: A Second Door

Nvidia also touched on NVLink Fusion, which lets other companies implement Nvidia's NVLink IP on their chips. This is how GB10 linked Mediatek's CPU die with an Nvidia GPU via NVLink C2C. NVLink Fusion would let customers connect custom CPUs—possibly RISC-V ones—to Nvidia GPUs using NVLink. The requirements include everything from CUDA plus support for frameworks like DOCA and NCCL, and a close partnership with Nvidia. That's a given, given the complexity of integrating IP.

What This Means for RISC-V

The RISC-V software ecosystem has a long way to go before it catches up to x86-64 and aarch64. Nvidia's CUDA port is a promising step, but it won't make every RISC-V board GPU-ready. Most existing hardware fails the requirements. ACPI alone is a hurdle that will take years to clear, if the aarch64 experience is any guide.

When CUDA-enabled RISC-V systems do appear, they'll be servers, not the single-board computers hobbyists tinker with. Nvidia is partnering with SiFive, and SiFive plans to demo a CUDA-running system at Hot Chips. The example CPU specs on Nvidia's slides suggest a high-core-count server chip.

The hope is that Nvidia doesn't lock CUDA out of unsupported systems. Enthusiasts would love to feed Nvidia GPUs from RISC-V boards, even if that means slower paths for some operations. Branches instead of predication can work if they're predictable. Cache invalidations cost performance, but that might be acceptable for compute-heavy workloads. Nvidia's requirements may be about expedience—a fast, low-risk port—rather than a permanent ceiling. Time will tell.