# Hot Chips 2026: CUDA Targets RISC-V – By Chester Lam > Source: > Published: 2026-08-24 16:52:01+00:00 CUDA is a giant for GPU compute, which includes machine learning applications. So far, CUDA supports x86-64 and aarch64 CPUs. Now, Nvidia is looking at extending CUDA support to RISC-V. This move opens the door for RISC-V CPUs to feed GPU compute. Nvidia’s talk focuses on the requirements that RISC-V CPUs must fulfill to work with CUDA. Basically, they want a server-grade CPU and platform. Nvidia starts by requiring a RVA23 CPU, and adherence to RISC-V’s [server SoC](https://docs.riscv.org/reference/server-soc/_attachments/riscv-server-soc.pdf) and [server platform](https://github.com/riscv-non-isa/riscv-server-platform/releases/tag/v1.0) specifications. Those specifications include RAS (reliability, availability, and serviceability) features, a specialized security processor, and other baseline features. Nvidia gets most of their server-grade expectations fulfilled by those specifications. Nvidia has a few more requirements that go beyond the RISC-V profile or platform specifications listed above, because they found it difficult to make CUDA software work well without those features. They don’t want a lowest common denominator problem, where they can’t use performance-enhancing extensions because they can’t guarantee they’ll be running on hardware with those extensions supported. From Nvidia’s perspective, that would force them to ship inefficient code. Nvidia brought up vector extensions as an example, because predication support lets them avoid branches. ACPI is a more difficult requirement. ACPI lets software discover what hardware can do, and can be used for power, performance, and thermal management. Nvidia’s software team wasn’t happy because RISC-V hardware didn’t have ACPI when they started porting CUDA, but that situation has been resolved. In 2025, the UEFI forum added RISC-V ACPI support. The RISC-V BRS (Boot and Runtime Services) specification was ratified last year, and includes ACPI. Then, Nvidia requires PCIe coherency. Nvidia brings up a memory ordering problem where the CPU has written data, but that data is sitting in a cache. If CUDA kicks off a DMA request to copy that data to the GPU, the DMA engines may read data from DRAM and miss modified data sitting in CPU-side caches. When copying results back from the GPU, the CPU could read stale data from its caches after the DMA engines write data to DRAM. Software would have to explicitly invalidate caches to avoid that scenario if the system doesn’t have PCIe coherency. Working cache invalidations into the CUDA stack would be difficult, and Nvidia considers PCIe coherency to be a standard feature in a server CPU. RISC-V’s server SoC specification recommends that hardware implement cache coherency, but Nvidia wants a guarantee. Nvidia also wants hardware to support peer-to-peer PCIe communication. Without this capability, buffers copied between two devices would have to go through CPU memory, which costs performance and increase complexity because it’ll need extra synchronization signals. Unfortunately, Nvidia didn’t go over all requirements in detail. They noted that they’re aiming for a certain level of performance, and that the overall list fits within two pages. It’s an open question whether it’s like two double-spaced pages with large font, or two note pages allowed for an open-note exam (which a student will creatively fill with as much information as possible). ## NVLink Fusion Requirements Besides running CUDA on RISC-V CPUs, Nvidia briefly went over requirements for NVLink Fusion. NVLink Fusion lets other companies implement Nvidia’s NVLink IP on their chips, letting them use Nvidia’s NVLink C2C link with a custom CPU of their choice. A hypothetical product would work much like Nvidia’s GB10, which linked Mediatek’s CPU die with an Nvidia GPU using NVLink C2C. Nvidia would of course want customers to use Nvidia’s CPUs as well. But if customers want to connect custom CPUs or other accelerators, Nvidia would still like them to use their NVLink IP. The custom CPU could be a RISC-V one. NVLink Fusion’s requirements include all of CUDA’s requirements, along with whatever’s needed to support software frameworks like DOCA and NCCL. Requirements extend to having a close partnership with Nvidia, which sounds like a given. Integrating IP can be a complex endeavor, and would likely require close cooperation along the lines of Mediatek’s cooperation with Nvidia for GB10. ## Impressions from Nvidia’s Talk RISC-V’s software ecosystem has some distance to go before catching up to x86-64 and aarch64. Nvidia’s effort to bring CUDA into the RISC-V world is a promising development. Unfortunately, those efforts don’t necessarily mean you can attach a Nvidia GPU to a RISC-V system and get cracking with CUDA. The vast majority of existing RISC-V hardware won’t meet Nvidia’s requirements. In fact, I would be surprised if any RISC-V consumer hardware meets those requirements in the near future. ACPI is an obvious sticking point, and seems difficult for vendors to pick up. In the aarch64 world, ACPI support has been spotty at best even though it has been [in standards for years](https://uefi.org/sites/default/files/resources/UEFI%20and%20ACPI%20in%20Arm%20System%20Architecture_Wei.pdf). A RISC-V standard ratified in 2025 would likely take several years to get wide support, if not more. When and if RISC-V systems start showing up with CUDA support, they’ll likely be server systems rather than the single board computers hobbyists can afford. Nvidia noted that they’re partnering with SiFive, and SiFive plans to demo a system running CUDA at Hot Chips. Nvidia implied the example CPU specifications on their slide correspond to that system, and those specifications suggest it’s a high core count server chip. I look forward to seeing that, but I also hope Nvidia doesn’t block CUDA from running on unsupported systems. I would love to see enthusiasts take a shot at feeding Nvidia GPUs from RISC-V systems. Going forward, I hope Nvidia can relax their requirements to give existing RISC-V systems a better chance of meeting them. Lack of vector extensions or PCIe coherency doesn’t necessarily lead to intractable performance problems. Using branches instead of predication can work well if those branches are predictable, which they often are. Cache invalidations required to work around lack of PCIe coherency will incur a performance cost. However, that cost may be acceptable for workloads that do a lot of compute compared to data movement. The same applies to PCIe peer-to-peer transfers. It’s great to have things go fast, but things that don’t happen often can be put on a slow path if you’re careful. Hopefully, Nvidia’s current requirements stem from expedience, and were set to allow a fast, low-risk RISC-V port. And hopefully, CUDA evolves in a way that makes it accessible to a wide range RISC-V systems, not just specialized enterprise designs.