logo
Kurashizu Blogwhere ideas flow
  • Home
  • News
  • Blog
  • About
  • Home
  • News
  • Blog
  • About

© 2026 Kurashizu. All rights reserved.

Admin·New Post·Service Status
Powered by Cloudflare·01.11.26
← Back to news

Hot Chips 2026: CUDA Targets RISC-V – By Chester Lam

Original article
chipsandcheese.com|22 points|3 comments|by rbanffy|Aug 24, 2026

Hot Chips 2026: Nvidia Brings CUDA to RISC-V

By Chester Lam

Chips and Cheese Chester Lam

In the realm of GPU acceleration, CUDA stands as the undisputed titan of software frameworks. In a significant strategic shift, Nvidia has revealed its intention to support CUDA on the RISC-V architecture. This development is pivotal because it enables RISC-V based CPUs to act as the primary "feeders" for high-performance GPU compute, particularly in machine learning.

The Technical Prerequisites for RISC-V

Nvidia's presentation focused heavily on the strict criteria a RISC-V CPU must meet to be compatible with CUDA. They are not looking for a "lowest common denominator" approach; doing so would force Nvidia to ship inefficient code by ignoring performance-boosting extensions.

Baseline Specifications

To start, Nvidia mandates the following:

  • RVA23 CPU Profile: The baseline architecture requirement.
  • Server SoC & Platform Specs: Adherence to RISC-V's official server standards.
  • RAS Features: Reliability, Availability, and Serviceability.
  • Security: A dedicated, specialized security processor.

Advanced Requirements

Beyond the standard profiles, Nvidia requires specific features to ensure software efficiency:

  1. Vector Extensions: Specifically, predication support is required to minimize the use of branches.
  2. ACPI (Advanced Configuration and Power Interface): Essential for hardware discovery and managing thermals, power, and performance. While initially missing from RISC-V hardware, this was resolved with the ratification of the BRS (Boot and Runtime Services) specification last year.

The Memory Coherency Challenge

A major point of contention is how the CPU and GPU handle data. Without proper hardware support, "stale data" becomes a critical risk.

The Problem: If a CPU writes data to a cache but hasn't flushed it to DRAM, a DMA (Direct Memory Access) request from the GPU will pull outdated information from the DRAM. Conversely, when the GPU writes back, the CPU might read old data from its own cache.

To solve this, Nvidia insists on PCIe coherency. While the RISC-V server spec recommends it, Nvidia demands it to avoid the complexity of manually invalidating caches within the CUDA stack.

Data Path Comparison

The following diagram illustrates the difference between standard memory copies and the Peer-to-Peer (P2P) communication Nvidia requires.

Without P2P, the performance cost is significant. We can represent the overhead as: Total Latency=LatencyGPU→CPU+LatencyCPU→GPU\text{Total Latency} = \text{Latency}_{\text{GPU}\to\text{CPU}} + \text{Latency}_{\text{CPU}\to\text{GPU}}Total Latency=LatencyGPU→CPU​+LatencyCPU→GPU​ With P2P, the CPU is bypassed entirely, reducing the complexity and synchronization signals required.


NVLink Fusion: Expanding the Ecosystem

Nvidia also introduced NVLink Fusion, a program allowing third parties to integrate Nvidia's NVLink IP into their own silicon. This allows a custom CPU to use the NVLink C2C (Chip-to-Chip) interconnect.

FeatureCUDA on RISC-VNVLink Fusion
Core RequirementRVA23 + Server SpecsAll CUDA Requirements
Software SupportCUDACUDA + DOCA + NCCL
PartnershipStandard CompatibilityClose Strategic Partnership
ExampleSiFive Server ChipGB10 (Mediatek CPU + Nvidia GPU)

Integrating this IP is complex. Nvidia noted that this requires a level of cooperation similar to their work with Mediatek for the GB10.


Final Impressions and Reality Check

While the news is promising, there is a significant gap between "supported" and "accessible."

The harsh reality:

  • Most current RISC-V hardware is not compatible.
  • Consumer-grade RISC-V boards will likely not meet these specs for years.
  • ACPI adoption is historically slow (even in the aarch64 ecosystem).

Nvidia is partnering with SiFive to demo a high-core-count server system running CUDA. However, the full list of requirements spans two pages—though whether those are "double-spaced" or "densely packed" remains a mystery.

# Hypothetical Compatibility Check
def check_cuda_compatibility(cpu):
    requirements = ["RVA23", "ACPI", "PCIe_Coherency", "P2P_Support"]
    for req in requirements:
        if req not in cpu.features:
            return False, f"Missing {req}"
    return True, "Compatible"

# Result for most hobbyist RISC-V boards:
# (False, "Missing ACPI")

Ultimately, I hope Nvidia relaxes these constraints. While predication and coherency improve performance, they aren't strictly "intractable" problems. Using branches instead of predication is perfectly viable if the branch predictor is efficient. I would love to see the enthusiast community experiment with feeding Nvidia GPUs from RISC-V systems, rather than keeping CUDA locked behind server-grade paywalls.