Nvidia werkt aan de integratie van CUDA op RISC-V CPU's, wat de weg vrijmaakt voor RISC-V om GPU-compute aan te sturen. Om dit mogelijk te maken, stelt Nvidia strikte eisen aan de hardware:
- Serverkwaliteit: Naleving van RVA23-specificaties en RAS-functies (reliability, availability, and serviceability).
- Systeembeheer: Ondersteuning voor ACPI via de RISC-V BRS-specificatie voor stroom- en thermisch beheer.
- Communicatie: PCIe-coherentie om handmatige cache-invalidaties te voorkomen en ondersteuning voor peer-to-peer PCIe-communicatie voor optimale prestaties.
Daarnaast wordt NVLink Fusion besproken, waarmee externe partijen NVLink IP kunnen implementeren op custom RISC-V CPU's in nauwe samenwerking met Nvidia. De auteur concludeert dat deze ontwikkelingen vooralsnog beperkt zullen blijven tot high-end serversystemen, aangezien de meeste huidige RISC-V-hardware niet aan deze eisen voldoet en consumentenhardware waarschijnlijk nog jaren op zich laat wachten.
Hot Chips 2026: CUDA richt zich op RISC-V
CUDA is het belangrijkste softwareframework in de wereld van GPU-compute, en Nvidia kijkt naar ondersteuning voor CUDA op RISC-V.
CUDA is een gigant op het gebied van GPU-compute, waaronder toepassingen voor machine learning. Tot nu toe ondersteunt CUDA x86-64 en aarch64 CPU's. Nu onderzoekt Nvidia de mogelijkheid om de CUDA-ondersteuning uit te breiden naar RISC-V. Deze stap opent de deur voor RISC-V CPU's om GPU-compute aan te sturen. De presentatie van Nvidia richt zich op de eisen waaraan RISC-V CPU's moeten voldoen om met CUDA te kunnen werken. In essentie zoeken ze naar een CPU en een platform van serverkwaliteit.
Technische vereisten voor CPU's
Nvidia begint met de eis van een RVA23 CPU en naleving van de RISC-V specificaties voor server SoC's en serverplatforms. Deze specificaties omvatten RAS-functies (reliability, availability, and serviceability), een gespecialiseerde beveiligingsprocessor en andere basiskenmerken. Hiermee wordt een groot deel van de verwachtingen van Nvidia voor serverkwaliteit vervuld.
Daarnaast heeft Nvidia een aantal aanvullende eisen die verder gaan dan de bovengenoemde RISC-V-profielen of platformspecificaties, omdat zij ontdekten dat het moeilijk was om CUDA-software goed te laten werken zonder deze functies. Ze willen een "laagste gemene deler"-probleem voorkomen, waarbij ze geen prestatieverbeterende extensies kunnen gebruiken omdat ze niet kunnen garanderen dat ze draaien op hardware die deze extensies ondersteunt. Vanuit het perspectief van Nvidia zou dit hen dwingen om inefficiënte code te leveren. Als voorbeeld noemde Nvidia vector-extensies, omdat ondersteuning voor predication hen in staat stelt om vertakkingen (branches) te vermijden.
ACPI en Systeembeheer
ACPI is een complexere vereiste. ACPI stelt software in staat om te ontdekken wat de hardware kan doen en kan worden gebruikt voor stroom-, prestatie- en thermisch beheer. Het softwareteam van Nvidia was ontevreden omdat RISC-V-hardware geen ACPI had toen zij begonnen met het porteren van CUDA, maar die situatie is inmiddels opgelost. In 2025 heeft het UEFI-forum ondersteuning voor RISC-V ACPI toegevoegd. De RISC-V BRS (Boot and Runtime Services) specificatie is vorig jaar geratificeerd en bevat ACPI.
PCIe Coherentie en Communicatie
Vervolgens vereist Nvidia PCIe-coherentie. Nvidia haalt hierbij een probleem met geheugenvolgorde aan waarbij de CPU gegevens heeft geschreven, maar die gegevens nog in een cache staan. Als CUDA een DMA-verzoek start om die gegevens naar de GPU te kopiëren, kunnen de DMA-engines gegevens lezen uit het DRAM en daarmee gewijzigde gegevens missen die in de CPU-caches staan. Bij het terugkopiëren van resultaten vanuit de GPU zou de CPU verouderde gegevens uit zijn caches kunnen lezen nadat de DMA-engines gegevens naar het DRAM hebben geschreven.
Als het systeem geen PCIe-coherentie heeft, zou software expliciet caches moeten ongeldig maken (invalidate) om dit scenario te voorkomen. Het integreren van cache-invalidaties in de CUDA-stack zou moeilijk zijn, en Nvidia beschouwt PCIe-coherentie als een standaardfunctie in een server-CPU. De RISC-V server SoC-specificatie adviseert dat hardware cache-coherentie implementeert, maar Nvidia wil hierover een garantie.
Daarnaast wil Nvidia dat hardware peer-to-peer PCIe-communicatie ondersteunt. Zonder deze mogelijkheid zouden buffers die tussen twee apparaten worden gekopieerd via het CPU-geheugen moeten lopen, wat ten koste gaat van de prestaties en de complexiteit verhoogt omdat er extra synchronisatiesignalen nodig zijn.
Nvidia is niet ingegaan op alle vereisten in detail, maar gaf aan dat ze streven naar een bepaald prestatieniveau en dat de volledige lijst op twee pagina's past.
Vereisten voor NVLink Fusion
Naast het draaien van CUDA op RISC-V CPU's, besprak Nvidia kort de vereisten voor NVLink Fusion. NVLink Fusion stelt andere bedrijven in staat om de NVLink IP van Nvidia te implementeren op hun eigen chips, waardoor ze de NVLink C2C-link van Nvidia kunnen gebruiken met een door hen gekozen custom CPU. Een hypothetisch product zou veel werken als Nvidia's GB10, waarbij de CPU-die van Mediatek werd gekoppeld aan een Nvidia GPU via NVLink C2C.
Hoewel Nvidia uiteraard wil dat klanten ook hun eigen CPU's gebruiken, wil Nvidia dat er hun NVLink IP wordt gebruikt als klanten custom CPU's of andere accelerators willen verbinden. Deze custom CPU zou een RISC-V CPU kunnen zijn.
De vereisten voor NVLink Fusion omvatten:
- Alle vereisten van CUDA.
- Alles wat nodig is om softwareframeworks zoals DOCA en NCCL te ondersteunen.
- Een nauwe samenwerking met Nvidia.
Het integreren van IP kan een complex proces zijn en zou waarschijnlijk een nauwe samenwerking vereisen, vergelijkbaar met de samenwerking tussen Mediatek en Nvidia voor de GB10.
Impressies van de presentatie van Nvidia
Het software-ecosysteem van RISC-V heeft nog een weg te gaan voordat het x86-64 en aarch64 kan bijbenen. De inspanningen van Nvidia om CUDA naar de RISC-V-wereld te brengen zijn een veelbelovende ontwikkeling. Helaas betekent dit niet noodzakelijkerwijs dat je een Nvidia GPU aan een RISC-V-systeem kunt koppelen en direct met CUDA aan de slag kunt.
De overgrote meerderheid van de bestaande RISC-V-hardware zal niet voldoen aan de eisen van Nvidia. Sterker nog, het zou me verbazen als er in de nabije toekomst consumentenhardware voor RISC-V is die aan deze eisen voldoet. ACPI is een duidelijk struikelblok en lijkt moeilijk voor leveranciers om te implementeren. In de aarch64-wereld is ACPI-ondersteuning op zijn best inconsistent, ondanks dat het al jaren in de standaarden staat. Een RISC-V-standaard die in 2025 is geratificeerd, zal waarschijnlijk enkele jaren nodig hebben om brede ondersteuning te krijgen.
Wanneer RISC-V-systemen met CUDA-ondersteuning verschijnen, zullen dit waarschijnlijk serversystemen zijn in plaats van de single board computers die hobbyisten zich kunnen veroorloven. Nvidia merkte op dat ze samenwerken met SiFive, en SiFive is van plan een systeem te demonstreren dat CUDA draait tijdens Hot Chips. Nvidia suggereerde dat de voorbeeld-CPU-specificaties op hun slide overeenkomen met dat systeem, en die specificaties wijzen op een serverchip met een hoog aantal kernen.
Ik hoop dat Nvidia CUDA niet blokkeert op niet-ondersteunde systemen; het zou geweldig zijn om te zien dat enthousiastelingen proberen Nvidia GPU's aan te sturen vanaf RISC-V-systemen. In de toekomst hoop ik dat Nvidia hun eisen kan versoepelen. Het ontbreken van vector-extensies of PCIe-coherentie leidt niet noodzakelijkerwijs tot onoplosbare prestatieproblemen. Het gebruik van vertakkingen in plaats van predication kan goed werken als die vertakkingen voorspelbaar zijn. Cache-invalidaties die nodig zijn bij het ontbreken van PCIe-coherentie zullen ten koste gaan van de prestaties, maar die kosten kunnen acceptabel zijn voor workloads waarbij veel rekenwerk wordt gedaan in verhouding tot dataverplaatsing. Hetzelfde geldt voor PCIe peer-to-peer transfers.
Hopelijk komen de huidige eisen van Nvidia voort uit opportunisme en zijn ze vastgesteld om een snelle, risicoarme RISC-V-port mogelijk te maken. En hopelijk evolueert CUDA zodanig dat het toegankelijk wordt voor een breed scala aan RISC-V-systemen, en niet alleen voor gespecialiseerde enterprise-ontwerpen.
Hot Chips 2026: CUDA richt zich op RISC-V
CUDA is het belangrijkste softwareframework in de wereld van GPU-compute, en Nvidia kijkt naar ondersteuning voor CUDA op RISC-V.
CUDA is een gigant op het gebied van GPU-compute, waaronder toepassingen voor machine learning. Tot nu toe ondersteunt CUDA x86-64 en aarch64 CPU's. Nu onderzoekt Nvidia de mogelijkheid om de CUDA-ondersteuning uit te breiden naar RISC-V. Deze stap opent de deur voor RISC-V CPU's om GPU-compute aan te sturen. De presentatie van Nvidia richt zich op de eisen waaraan RISC-V CPU's moeten voldoen om met CUDA te kunnen werken. In essentie zoeken ze naar een CPU en een platform van serverkwaliteit.
Technische vereisten voor CPU's
Nvidia begint met de eis van een RVA23 CPU en naleving van de RISC-V specificaties voor server SoC's en serverplatforms. Deze specificaties omvatten RAS-functies (reliability, availability, and serviceability), een gespecialiseerde beveiligingsprocessor en andere basiskenmerken. Hiermee wordt een groot deel van de verwachtingen van Nvidia voor serverkwaliteit vervuld.
Daarnaast heeft Nvidia een aantal aanvullende eisen die verder gaan dan de bovengenoemde RISC-V-profielen of platformspecificaties, omdat zij ontdekten dat het moeilijk was om CUDA-software goed te laten werken zonder deze functies. Ze willen een "laagste gemene deler"-probleem voorkomen, waarbij ze geen prestatieverbeterende extensies kunnen gebruiken omdat ze niet kunnen garanderen dat ze draaien op hardware die deze extensies ondersteunt. Vanuit het perspectief van Nvidia zou dit hen dwingen om inefficiënte code te leveren. Als voorbeeld noemde Nvidia vector-extensies, omdat ondersteuning voor predication hen in staat stelt om vertakkingen (branches) te vermijden.
ACPI en Systeembeheer
ACPI is een complexere vereiste. ACPI stelt software in staat om te ontdekken wat de hardware kan doen en kan worden gebruikt voor stroom-, prestatie- en thermisch beheer. Het softwareteam van Nvidia was ontevreden omdat RISC-V-hardware geen ACPI had toen zij begonnen met het porteren van CUDA, maar die situatie is inmiddels opgelost. In 2025 heeft het UEFI-forum ondersteuning voor RISC-V ACPI toegevoegd. De RISC-V BRS (Boot and Runtime Services) specificatie is vorig jaar geratificeerd en bevat ACPI.
PCIe Coherentie en Communicatie
Vervolgens vereist Nvidia PCIe-coherentie. Nvidia haalt hierbij een probleem met geheugenvolgorde aan waarbij de CPU gegevens heeft geschreven, maar die gegevens nog in een cache staan. Als CUDA een DMA-verzoek start om die gegevens naar de GPU te kopiëren, kunnen de DMA-engines gegevens lezen uit het DRAM en daarmee gewijzigde gegevens missen die in de CPU-caches staan. Bij het terugkopiëren van resultaten vanuit de GPU zou de CPU verouderde gegevens uit zijn caches kunnen lezen nadat de DMA-engines gegevens naar het DRAM hebben geschreven.
Als het systeem geen PCIe-coherentie heeft, zou software expliciet caches moeten ongeldig maken (invalidate) om dit scenario te voorkomen. Het integreren van cache-invalidaties in de CUDA-stack zou moeilijk zijn, en Nvidia beschouwt PCIe-coherentie als een standaardfunctie in een server-CPU. De RISC-V server SoC-specificatie adviseert dat hardware cache-coherentie implementeert, maar Nvidia wil hierover een garantie.
Daarnaast wil Nvidia dat hardware peer-to-peer PCIe-communicatie ondersteunt. Zonder deze mogelijkheid zouden buffers die tussen twee apparaten worden gekopieerd via het CPU-geheugen moeten lopen, wat ten koste gaat van de prestaties en de complexiteit verhoogt omdat er extra synchronisatiesignalen nodig zijn.
Nvidia is niet ingegaan op alle vereisten in detail, maar gaf aan dat ze streven naar een bepaald prestatieniveau en dat de volledige lijst op twee pagina's past.
Vereisten voor NVLink Fusion
Naast het draaien van CUDA op RISC-V CPU's, besprak Nvidia kort de vereisten voor NVLink Fusion. NVLink Fusion stelt andere bedrijven in staat om de NVLink IP van Nvidia te implementeren op hun eigen chips, waardoor ze de NVLink C2C-link van Nvidia kunnen gebruiken met een door hen gekozen custom CPU. Een hypothetisch product zou veel werken als Nvidia's GB10, waarbij de CPU-die van Mediatek werd gekoppeld aan een Nvidia GPU via NVLink C2C.
Hoewel Nvidia uiteraard wil dat klanten ook hun eigen CPU's gebruiken, wil Nvidia dat er hun NVLink IP wordt gebruikt als klanten custom CPU's of andere accelerators willen verbinden. Deze custom CPU zou een RISC-V CPU kunnen zijn.
De vereisten voor NVLink Fusion omvatten:
- Alle vereisten van CUDA.
- Alles wat nodig is om softwareframeworks zoals DOCA en NCCL te ondersteunen.
- Een nauwe samenwerking met Nvidia.
Het integreren van IP kan een complex proces zijn en zou waarschijnlijk een nauwe samenwerking vereisen, vergelijkbaar met de samenwerking tussen Mediatek en Nvidia voor de GB10.
Impressies van de presentatie van Nvidia
Het software-ecosysteem van RISC-V heeft nog een weg te gaan voordat het x86-64 en aarch64 kan bijbenen. De inspanningen van Nvidia om CUDA naar de RISC-V-wereld te brengen zijn een veelbelovende ontwikkeling. Helaas betekent dit niet noodzakelijkerwijs dat je een Nvidia GPU aan een RISC-V-systeem kunt koppelen en direct met CUDA aan de slag kunt.
De overgrote meerderheid van de bestaande RISC-V-hardware zal niet voldoen aan de eisen van Nvidia. Sterker nog, het zou me verbazen als er in de nabije toekomst consumentenhardware voor RISC-V is die aan deze eisen voldoet. ACPI is een duidelijk struikelblok en lijkt moeilijk voor leveranciers om te implementeren. In de aarch64-wereld is ACPI-ondersteuning op zijn best inconsistent, ondanks dat het al jaren in de standaarden staat. Een RISC-V-standaard die in 2025 is geratificeerd, zal waarschijnlijk enkele jaren nodig hebben om brede ondersteuning te krijgen.
Wanneer RISC-V-systemen met CUDA-ondersteuning verschijnen, zullen dit waarschijnlijk serversystemen zijn in plaats van de single board computers die hobbyisten zich kunnen veroorloven. Nvidia merkte op dat ze samenwerken met SiFive, en SiFive is van plan een systeem te demonstreren dat CUDA draait tijdens Hot Chips. Nvidia suggereerde dat de voorbeeld-CPU-specificaties op hun slide overeenkomen met dat systeem, en die specificaties wijzen op een serverchip met een hoog aantal kernen.
Ik hoop dat Nvidia CUDA niet blokkeert op niet-ondersteunde systemen; het zou geweldig zijn om te zien dat enthousiastelingen proberen Nvidia GPU's aan te sturen vanaf RISC-V-systemen. In de toekomst hoop ik dat Nvidia hun eisen kan versoepelen. Het ontbreken van vector-extensies of PCIe-coherentie leidt niet noodzakelijkerwijs tot onoplosbare prestatieproblemen. Het gebruik van vertakkingen in plaats van predication kan goed werken als die vertakkingen voorspelbaar zijn. Cache-invalidaties die nodig zijn bij het ontbreken van PCIe-coherentie zullen ten koste gaan van de prestaties, maar die kosten kunnen acceptabel zijn voor workloads waarbij veel rekenwerk wordt gedaan in verhouding tot dataverplaatsing. Hetzelfde geldt voor PCIe peer-to-peer transfers.
Hopelijk komen de huidige eisen van Nvidia voort uit opportunisme en zijn ze vastgesteld om een snelle, risicoarme RISC-V-port mogelijk te maken. En hopelijk evolueert CUDA zodanig dat het toegankelijk wordt voor een breed scala aan RISC-V-systemen, en niet alleen voor gespecialiseerde enterprise-ontwerpen.
Groetjes,