RDNA 4 starts with the Command Processor

AMD's front end consumes command streams through the Command Processor. Kernel dispatches can then flow through Asynchronous Compute Engines, which allow separate queues and kernels to make progress without serializing every compute operation.

Workgroups eventually reach the Shader Processor Input, or SPI. This is one of the key hardware scheduling points in the Radeon hierarchy.

AMD's own ROCm documentation describes the SPI as the component responsible for placing workgroups onto available Compute Units. It considers resident wave slots, vector and scalar registers and Local Data Share capacity before deciding where another workgroup can fit.

The mapping is resource-driven rather than a simple round-robin assignment.

The problem gets smaller once a wave reaches a CU

Inside the execution units, scheduling moves from workgroups to individual wavefronts. RDNA Radeon hardware is designed primarily around Wave32 execution, although RDNA 4 also supports Wave64.

A resident wave may stall while waiting for memory or another dependency. Hardware can select another ready wave instead, allowing useful arithmetic to continue without waiting for the first one to become runnable again.

That only works when enough independent waves are resident. Register usage, LDS allocation and workgroup size therefore influence how much latency the scheduler can hide.

Blackwell moves the local decision inside each SM partition

NVIDIA uses thread blocks rather than AMD's workgroup terminology and warps rather than wavefronts. A warp is 32 threads.

On GeForce Blackwell, each Streaming Multiprocessor is divided into four processing partitions. Each partition includes its own warp scheduler, register file and L0 instruction cache.

A Blackwell SM therefore has four warp schedulers deciding which ready warps can issue work into the available execution pipelines.

The concept is familiar across several NVIDIA generations, although Blackwell changes the surrounding SM substantially. Its 128 shader ALUs can now handle FP32 and integer operations across all four partitions rather than retaining Ada's previous split between mixed and FP32-only datapaths.

Wave32 and a 32-thread warp are similar, not interchangeable

The matching thread count can make the two architectures look closer than they are. A Wave32 and a warp both carry 32 lanes under a common instruction stream, but residency and resource accounting are organised around different hardware structures.

AMD places work through its Shader Engines and CUs, with the SPI tracking the resources required to admit another workgroup. NVIDIA admits thread blocks onto SMs and then exposes four local warp-scheduling partitions inside each SM.

A shader using more registers can reduce occupancy on either architecture. The exact threshold and resulting number of resident waves or warps are different.

Occupancy is what gives either scheduler something to choose from

A scheduler cannot hide latency if there is no second ready group of threads waiting to run.

For an RX 9000 GPU, VGPR pressure, SGPR usage and LDS consumption can limit the number of wavefronts and workgroups that remain resident on a Compute Unit.

On GeForce Blackwell with compute capability 12.0, NVIDIA documents a maximum of 48 concurrent warps per SM, 64K 32-bit registers per SM and as many as 32 blocks per SM, with the real result constrained by the resources required by each block.

Those limits explain why theoretical shader count alone says little about utilisation. A poorly shaped workload can leave arithmetic hardware idle on either vendor.

Blackwell adds more machinery for persistent work

The scheduling discussion becomes more unusual with newer CUDA mechanisms such as Thread Block Clusters and Blackwell's Cluster Launch Control.

Cluster Launch Control can be used by persistent kernels to dynamically obtain new tiles of work. NVIDIA's CUTLASS library uses a dedicated scheduler warp to request and distribute this work in some Blackwell matrix-multiplication kernels.

Care is needed when translating those capabilities to gaming products. NVIDIA's Blackwell family covers multiple compute capabilities, and features documented for datacenter-class Blackwell are not automatically present in every GeForce RTX 50 GPU.

RDNA 4 keeps a more familiar Radeon scheduling hierarchy

RDNA 4 made major changes to ray tracing, matrix operations and AI acceleration, but AMD's documented high-level scheduling path remains recognisably RDNA: Command Processor, asynchronous engines, SPI workgroup placement and local wave execution inside the compute hardware.

AMD's RDNA 4 ISA explicitly retains both 32-lane and 64-lane wave modes. Current ROCm specifications list the RX 9070 XT, RX 9070 and RX 9060 XT as supporting Wave32 and Wave64.

None of this makes the driver irrelevant

Hardware scheduling begins after a considerable amount of software work has already happened. Drivers build and submit command streams, manage contexts and dependencies and provide compiled shader code to the GPU.

The chip then handles decisions at the timescale where software running on the CPU could never efficiently intervene for every warp or wave.

This is also separate from Windows Hardware-Accelerated GPU Scheduling. HAGS changes how Windows, the driver and GPU handle higher-level scheduling and context queues. A Blackwell warp scheduler or RDNA wave scheduler operates much deeper inside the execution pipeline.

The shortest version is two scheduling hierarchies

On RDNA 4, work moves through the Command Processor and ACEs to the SPI, which decides which Compute Units can accept workgroups based on available execution contexts, registers and LDS. Local hardware then chooses between resident waves.

On Blackwell, thread blocks are distributed onto Streaming Multiprocessors. Each SM contains four processing partitions with a warp scheduler that selects ready warps for execution.

Both architectures are trying to solve the same problem: keep enough independent work resident that an ALU does not have to sit idle whenever one group of threads hits a cache miss or dependency.