Every Nvidia GPU has 10 to 30 RISC-V cores inside it

RISC-V has been around for a long time, but its big breakthrough always seems to be just around the corner. Maybe it'll turn up in a laptop one day, or a server, or your phone, but every year it feels as if all we get are development boards from the likes of SiFive. Here's the thing, though: Nvidia thinks it shipped over a billion RISC-V cores in 2024, even if they're not your typical computing-oriented chips.

Specifically, those RISC-V cores are in Nvidia's GPUs, but they're not in the shader cores. Instead, they're in the collective of small management processors doing all kinds of additional work around the graphics processing, and Nvidia reckons each GPU has 10 to 40 of them, depending on the model.

Users can't program them, and in fact, the sensitive cores are cryptographically verified and won't even allow the GPU firmware to boot if they've been tampered with. However, there's one particular core that's been doing a huge amount of the work that used to be your graphics driver, and it's been doing it since 2018.

Nvidia's GPUs were using proprietary microcontrollers for a decade

The FAst Logic CONtroller did quite a lot

Before RISC-V came to the Nvidia series, the company was using Falcon, a shorthand of FAst Logic CONtroller, and its first appearance was sometime around 2005 with the G98 generation. At the time, it replaced the Tensilica Xtensa cores that Nvidia had been using for its VP2 video decoding. It's a pipelined design which supports a variable-length instruction set, completely proprietary, and it was built for low die area and long memory latency instead of raw speed; Nvidia just kept adding more as GPUs increased in complexity.

By 2016, Falcons could be found in more than 15 different engines on a single chip, and Nvidia estimated that it had shipped approximately three billion of them across the decade. They were doing things like video decoding and encoding, power management, the security engine, and a whole lot more. They were everywhere, and they were a crucial part of Nvidia's architecture at this point, given that the on-die boot ROM validated signed firmware before execution.

That signature requirement is what caused issues for Linux users; from September 2014 onwards, Nvidia told nouveau's developers that Maxwell-era GPUs and later would have parts of the chip only respond to firmware images signed by Nvidia. This prevented Linux users from doing things like changing the GPU's clock speeds, often leaving them at boot clocks. However, it quickly became apparent that Falcon was not cut out for what it was being asked to do a decade after it was first built.

Nvidia shopped around, and Arm lost

Others lost too, though

Nvidia has been rather blunt about why it doesn't use Falcon anymore. In 2024, Frans Sijstermans, Vice President of Hardware Engineering at Nvidia, stated that "one of the main reasons why we switched away from Falcon is that we didn't have 64 bit address spaces. The Falcon was a 32-bit core. We needed 64." However, it also had no data cache, and it couldn't run a real operating system either.

In 2016, Nvidia went to the drawing board, evaluating whether it could buy a license for a core, or if it should just build its own. Arm's A and R families were on the table, as was Synopsys ARC, MIPS, and Cadence. Building, though, involved potentially improving Falcon or moving to a new instruction set entirely. In hindsight, it's pretty hilarious that Nvidia then went on to publish this evaluation table, because it's a fairly brutal takedown of some of the company's own suppliers.

Starting with Arm, the Cortex-A53 failed primarily on die area, as it needed to come in under 0.1mm^2 on a 16nm process, which it couldn't. On top of that, it needed to have an extensible ISA. The Cortex-A9 and the Cortex-R5 both failed for multiple reasons, too, including the need for 64-bit addressing. Synopsys ARC HS failed on security and addressing. Even Nvidia's own Falcon, if improved, couldn't hit the performance target or the address space.

In fact, RISC-V didn't sweep the entire table. Nvidia also tested Rocket, a reference core from Berkeley, but it failed on tightly-coupled memory and on having a functional simulation model. The instruction set of RISC-V is what set it apart. The result was a core that smoked the original Falcon core, achieving three times the performance for only twice the area.

A single Nvidia chip can have dozens of RISC-V cores

There are a few different types of RISC-V cores from Nvidia

In 2024, Sijstermans talked about his "personal, unofficial guesstimate", so make of that what you will. He at least explained his reasoning, saying that "Any Nvidia chip has RISC-V processors. And I would say it goes from 10 RISC-V processors to about 30, maybe even 40 RISC-V processors per chip. You know how many chips we sell roughly, right? You can find that on the internet." He called his billion-core estimate conservative, and said it's likely somewhere between one and two billion cores every year.

The reason that number can change is because the core count scales with the size of the GPU; the GPC Context Switch, or GPCCS, is instantiated per graphics processing cluster, and a full Ada Lovelace AD102 has 12 GPCs. Then add on the video engines, three NVENC and three NVDEC units, and any others that are necessary, and you can get to 30 or 40 pretty quickly.

You can actually see this inside of Nvidia's open kernel modules, in the rmlsfm.h header file. This file contains a list of all of the microcontrollers that the driver knows about, and it contains 32 distinct entries. The first 12 are all Falcon units, but out of the remaining 20, 14 of them are RISC-V engines. These include GSP_RISCV, PMU_RISCV, NVDEC_RISCV, and more. Interestingly, register headers in Nvidia's open kernel modules already cover Rubin, the architecture after Blackwell. dev_riscv_pri.h exists for rubin/gr100 and rubin/gr102.

There are three primary core designs in use here, all built by Nvidia. NV-RISCV32 is an in-order RV32I-MU core with NV-RISCV64 being the bigger out-of-order core based on the RV64I-MSU with bit manipulation, atomics, and symmetric multiprocessing support. Finally, NV-RVV is a 32-bit core with a 1024-bit vector unit attached, and it's part of the Deep Learning Accelerator. Each core comes wrapped in a reusable subsystem called "Peregrine," which attaches cache, tightly-coupled memory, a DMA engine, and a set of crypto blocks onto an NV-RISCV core.

Nvidia has also built more than 20 of its own extensions; there's a 64-bit physical and virtual addressing extension, 2KB page sizes, secure debug, ROM protection, and cache operation instructions. It's useless to basically anyone else, but it's exactly what Nvidia needed.

The largest is important for the graphics driver

The GPU System Processor is the heart of your GPU

The GPU System Processor is the most important of these; rather than being a single core, it's packing four RV64 cores behind a platform-level interrupt controller. On top of that, there's an IOPMP for memory isolation, a DMA engine, a host interface and mailbox, unified tightly-coupled memory and cache, and a coherent fabric that goes across the entire GPU. It's at the very top of the chip, and practically all traffic goes through it.

On every generation since Turing, the resource manager gets split in two. CPU-RM runs on the processor, GSP-RM runs on the GPU's RISC-V cores, and they communicate over an RPC messaging queue. The kernel driver on the host can then send high-level commands to the GSP, and the GSP handles functions including initialization, power management, and clock speeds. In other words, a lot of the GPU driver you install is really enabling your computer to send commands to another computer inside of your GPU.

I analyzed the firmware file, nvidia/ga102/gsp/gsp-535.113.01.bin, and it's pretty interesting. It's a 36.3MB file containing four separate 4KB RSA signature sections, one each for Ampere GA10x, Ada AD10x, Hopper GH100, and a confidential-compute variant of the H100. The file itself is just an ELF64 targeting EM_RISCV.

In that firmware, I found references to libos-v3.1.0, alongside tests that mention partitions[partitionOwner].pmp[...] and PmpEntryFree. LibOS is Nvidia's own microkernel, and it uses PMP to isolate partitions, which is the standard RISC-V physical memory protection mechanism. I also verified from nvidia/tu102/gsp/gsp-535.113.01.bin that the strings are identical, meaning that Turing's GSP is RISC-V-based, too.

The reason Nvidia does it this way is to enable lower-latency access to hardware internals with a significantly reduced MMIO communication surface exposed to the host. With the GSP running a separation kernel, a single physical GPU can be partitioned into guest VMs without the hypervisor being in the path. Nvidia's vGPU software is primarily an enterprise solution that consumers can't avail of normally, but users have figured out how to enable vGPUs on consumer cards, and the GSP is a significant part of what enables that separation.

An open instruction set doesn't mean an open GPU

You can still treat RISC-V as closed

RISC-V is an open ISA, but unfortunately, Nvidia's GPUs are anything but. Those four RSA signature blocks are doing a lot of work; for starters, the GSP won't execute an image where the signature doesn't validate for that GPU family, and the boot chain is arranged so the security engine authenticates the runtime firmware before it ever starts. RISC-V being an open standard doesn't change that, and Nvidia was pretty explicit about the fact that RISC-V was chosen, at least in part, because its isolation and memory-protection features made this kind of lockdown easier to build.

For nouveau developers, this has (understandably) been frustrating. A lot of the control logic that was previously open moved to an opaque binary without a stable ABI and a lot of undocumented calls, and firmware images are large and bloated for Linux machines running Nvidia cards as a result. On the bright side, this is partially why the open driver is at least decent, as Nvidia now supplies a signed GSP firmware that nouveau is permitted to load.

With that, open drivers were able to control clock speeds on Nvidia GPUs and run them at full speed, which had been taken away from Linux users with Maxwell's launch in 2014. By giving more control to the RISC-V processor, an open driver was now able to do more with the GPU than it otherwise would have been able to.

Nova, the Rust-based successor to nouveau, explicitly supports the GSP, and it includes definitions like "PeregrineCoreSelect" for picking the core that comes up during boot. We've come a long way compared to a decade ago, even if it's come at the expense of a truly open GPU driver.

AMD went the opposite way

It's hard to even find information

Nvidia isn't unique in its move towards bundling dozens of microcontrollers with its GPUs, and AMD did the same thing. The difference is that AMD runs a collection of unrelated architectures with no common instruction set that bundles them all together. As far as public reverse engineering shows, none of them are RISC-V-based, but there's a complete lack of information from AMD on this front. The Platform Security Processor used these days appears to be an Arm Cortex-A5 with TrustZone and the System Management Unit appears to be Tensilica Xtensa, though earlier generations seemed to use a LatticeMico32.

On AMD cards, the command processors, the PFP, ME, and MEC units that pull work off the GPU's command queues, all run something that AMD refers to as "F32." What's more, we only know that because fail0verflow wrote a disassembler for it. It's probably as far as you can get from a general-purpose ISA as you can get, and it's more or less what Nvidia decided not to build back in 2016. Even its registers are purpose-built for what essentially amounts to a CPU built to be a GPU front-end and nothing more.

In F32, register r0 is hardwired to zero, r1 pops dwords off of the GPU's command queue when read, r2 holds the current command packet header, and there's a dedicated btab instruction that looks up packet types in a jump table stored in the firmware and branches there.

It's not that AMD is avoiding RISC-V, either, given that the company is a RISC-V International member and has been since 2020. Its MicroBlaze V, launched with Vivado 2024.1, is a true RV32I processor that AMD sells to FPGA customers as a drop-in replacement for its own proprietary MicroBlaze core. Both companies have swapped an in-house ISA for RISC-V somewhere, but Nvidia did it in the invisible internals that nobody can buy.

Nvidia's own GSP blob is a standard ELF that you can easily analyze, but AMD's equivalent GPU firmware blobs across RDNA 3, RDNA 4, PSP, SMU, display, and video didn't yield architectural hints or so much as a compiler-related string when I analyzed those.

Why Nvidia's RISC-V work stayed invisible

You don't need to know

Sijstermans spent a lot of time talking about why Nvidia's RISC-V work hasn't been common knowledge, and there's a rather simple explanation. "Most people, if they think RISC-V they don't think Nvidia," he said, "or if you think Nvidia you don't think RISC-V, and that's because most of our designs are done in-house, our software is developed in-house, it's not customer facing."

Things are starting to close in on RISC-V from the other end, though, as it was announced in 2025 during the RISC-V Summit in Shanghai that Nvidia is porting CUDA to run on RISC-V processors. That would mean a RISC-V CPU can drive an Nvidia GPU as the main application processor, in the same way that you can already on x86 and Arm. There wasn't a timeline given, and it depends on data-center-class RISC-V silicon that doesn't really exist yet, but it's clear that Nvidia sees value in the platform. Enough value to invest in it, anyway.

When Nvidia's CUDA port is made available for RISC-V, it'll be seen as RISC-V's arrival in serious computing. But the thing is, that already happened a decade ago. Nvidia's cores have been in its GPUs all this time, quietly bringing up your display and deciding how fast your fans spin, and the reason most people never noticed is simple: Nvidia never had any reason to tell you.