NVIDIA took the stage at Hot Chips 2026 to talk about RISC-V for NVIDIA GPUs. We wanted to cover a few of the RISC-V presentations, but on Sunday we were a bit behind. So we are catching up now. As a fun aside, this was a tutorial day session, so it is not one where we saw the same two opening slides that we did in the other NVIDIA Hot Chips presentation.
NVIDIA RISC-V for NVIDIA GPUs at Hot Chips 2026
NVIDIA structured the talk around two platforms, CUDA and NVLink Fusion. Host CPUs have a defined role in each one, and NVIDIA laid out the requirements RISC-V CPUs would need to meet along with the opportunities and challenges of bringing more of its stack to RISC-V. CUDA dates back to 2006 as a parallel computing platform and the idea is how it can integrate CUDA and RISC-V.
CUDA applications split work between CPU and GPU software modules. Compute-intensive functions are parallelized on the GPU while the rest of the application runs sequentially on the CPU.
This host CPU software stack is complex and heterogeneous. Application modules mix CPU-only and CUDA-accelerated components. CUDA libraries, drivers, and tools plus third-party software for the target CPU sit on top. NVIDIA already supports Intel/AMD x86 CPUs along with Arm CPUs on the CPU side.
For RISC-V CPUs to run CUDA, NVIDIA points to RISC-V server-related specifications. RVA23 profiles and the RISC-V Boot and Runtime Services specification cover the application layer. These RISC-V server SoC and platform specifications define the system level.
Software binary compatibility is a central goal. NVIDIA says the RVA23 profile guarantees key extensions are present, so software runs across a variety of RISC-V processors without a lowest common denominator problem. While there is a lot of talk about RISC-V being the wild-west in terms of capabilities, the RISC-V folks are doing major and minor releases to define when mandatory and optional new extensions are adopted.
ACPI is one example of a RISC-V platform requirement. This UEFI Forum added RISC-V support in ACPI 6.6, ratified in May 2025, and the RISC-V Boot and Runtime Services specification followed in August 2025. We are only about a year onward from that happening.
CUDA workloads rely on data movement between host and device memory. A single operation moves through host-to-device copies, a kernel launch, device-to-host copies, and CPU work in between.
PCIe coherency is a CUDA-specific requirement that NVIDIA sees in most, possibly all, modern server CPUs. Hardware-based PCIe I/O coherence avoids frequent cache flush and invalidate operations. That simplifies software and improves latency.
PCIe peer-to-peer communication is the other CUDA-specific requirement shown. In multi-GPU systems, a GPU writes data directly to another GPU’s device memory and signals the host through flags. That avoids an extra copy through host memory. This was one of the big reasons we saw funky designs in GPU servers even a decade ago.
Vera Rubin is a full-stack AI factory platform built through co-design across seven chips and five racks. This platform extends from the Vera CPU and Rubin GPU, through networking, storage, and a scale-out fabric, to the rack itself. This slide would end up being used a few times this week.
NVIDIA’s NVL72 rack packs a 72-GPU L1 domain into a fully copper domain. Each compute tray holds GPUs on NVLink Fusion chiplets, with two Vera CPUs and C2C links between the CPU and the GPU. NVIDIA has its Grace, and now Vera Arm-ISA based CPus, but the platform is much broader.
NVLink Fusion is how custom silicon connects into the NVIDIA AI platform. Custom CPUs attach to the XPUs over NVLink C2C, giving each XPU high bandwidth while the rack keeps a single L1 domain.
Inside a custom CPU, NVIDIA shows the C2C interface integration. This NVLink C2C PHY provides a CPU-to-GPU high-bandwidth interface with CHI coherence. CPU and GPU can then access all memory under a unified memory architecture.
NVLink Fusion CPUs inherit all CUDA requirements and add more. NVIDIA points to a high-speed C2C interconnect with around 88 PCIe lanes and software such as DOCA for networking and NCCL for multi-GPU communication. This talk is really interesting now since these requirements are not ones we see discussed often. SiFive is being noted as the NVLink Fusion CPU partner that is RISC-V based.
NVIDIA closes by making the case for RISC-V in server platforms. An open standard with multiple vendors, combined with standardization and customization, broadens server CPU choice alongside x86 and Arm. “NVIDIA has plans for RISC-V in its platforms” there you go. We should probably point out that NVIDIA uses RISC-V in its current platforms for some of the lower-level controllers, but this is a presentation about host CPUs.
Taken together, these figures show how NVIDIA sees RISC-V fitting into the CUDA and NVLink Fusion platforms.
Final Words
NVIDIA’s roadmap makes clear that RISC-V is moving toward a genuine third option in the server CPU market alongside x86 and Arm. Published requirements, from RVA23 compliance to NVLink Fusion integration, will shape what RISC-V server silicon must deliver to earn a slot in future GPU platforms. We still are maybe two generations from broader RISC-V processor deployment, but folks in the industry say it is coming.
