GPU Shader Cores Explained: CUDA Cores, Stream Processors, SIMD Width, Warps, and Waves

Consumer GPU specification tables often expose a large shader-resource count: NVIDIA uses CUDA cores, while AMD commonly lists stream processors. Those labels are useful inside the context of a particular architecture, but they are not equivalent to CPU cores and they are not a vendor-neutral unit that can be compared one-for-one across unrelated GPU designs.

A shader program is executed through a larger machine that includes multiprocessors or compute units, schedulers, register files, caches, memory paths and specialized execution resources. The advertised arithmetic lanes are only one part of that machine. Comparing 10,000 resources on one architecture with 10,000 on another therefore does not establish equal throughput, gaming performance, efficiency or capability.

NVIDIA CUDA documentation describes the Streaming Multiprocessor, or SM, as the hardware unit that receives thread blocks, partitions their threads into warps and schedules those warps for execution. Current CUDA documentation defines a warp as 32 threads. A warp scheduler selects a ready warp and issues its next instruction to the active threads.

CUDA cores sit inside that broader SM organization and are used for arithmetic supported by those datapaths. The exact mix and organization are generation-specific. NVIDIA documentation, for example, shows that even products within historical Pascal used different CUDA-core counts per SM, while current compute-capability tables expose different occupancy limits across newer architectures. “One SM” and “one CUDA core” are therefore not interchangeable concepts.

AMD uses different terminology. Its RDNA documentation organizes shader execution around compute units and work group processors, with vector SIMD execution resources inside them. AMD’s RDNA instruction-set documentation introduced Wave32 alongside Wave64 and describes a work group processor as grouping compute resources so work can be scheduled across them.

Current AMD HIP documentation gives a concrete RDNA3 example: a work group processor contains two closely coupled compute units, each CU has two 32-wide SIMD units, and the primary Wave32 mode groups 32 work-items for execution. This architectural description is more useful than treating every listed stream processor as a tiny independent CPU core.

NVIDIA calls its scheduled groups warps; AMD calls analogous groups wavefronts or waves. These are execution-group concepts. They describe how many software threads or work-items advance together through SIMT/SIMD execution, not an additional bank of physical “warp cores” or “wave cores.”

NVIDIA specifies a warp size of 32 in current CUDA documentation. AMD RDNA supports Wave32 and, depending on architecture and mode, Wave64 behavior. Do not generalize one vendor’s grouping or one generation’s native width into a permanent GPU-wide rule. The scheduler, issue behavior and underlying datapaths are architecture-specific.

SIMD width describes the width of a vector execution organization: how many lanes can participate in an operation under the relevant execution model. A published stream-processor or CUDA-core total counts particular arithmetic resources. Issue width describes what instructions a scheduler or execution partition can dispatch in a given interval. These quantities can interact, but substituting one for another produces misleading architecture comparisons.

This is also why a raw shader count multiplied by boost clock is not a universal GPU performance formula. The result omits architecture-specific instruction throughput, utilization, scheduling, data types, memory behavior, caches, front-end limits, specialized units and workload characteristics. Even theoretical FLOPS requires architecture- and operation-specific rules rather than a generic core-count equation.

Within a sufficiently similar GPU family, shader-resource counts can help explain one structural difference between models. They are still not a benchmark: clock behavior, memory configuration, power limits, disabled resources and other specifications can differ. Across architecture generations the interpretation becomes weaker because the surrounding execution machinery can change.

Across NVIDIA and AMD the one-for-one comparison is weaker still. CUDA core and stream processor are vendor architecture labels, not a common standards-defined performance unit. A higher numerical count on either side does not by itself prove higher rasterization FPS, ray-tracing speed, compute throughput, AI performance or efficiency.

Modern GPUs also contain resources aimed at workloads beyond ordinary scalar or vector shader arithmetic. NVIDIA specification tables separately identify Tensor and ray-tracing cores, while AMD products separately expose resources such as AI and ray accelerators. Their presence is another reason a single shader-core total cannot summarize the whole processor.

Do not add unlike resources together into a larger “total core” number. Matrix acceleration, ray traversal/intersection work, texture operations, rasterization and general shader arithmetic have different jobs and architectures. Compare the relevant capability with suitable specifications and measurements for the workload instead.

If the question is how a GPU executes shader work, start with the architecture and programming documentation: identify the SM or CU/WGP organization, warp or wave size, execution resources and generation-specific behavior. That establishes what the labels mean without pretending they are universal.

If the question is which GPU is faster, use representative measurements from the actual workload and settings. Shader counts can provide architectural context for those results, but they cannot replace them. The same rule applies to efficiency, latency and specialized compute: measure the outcome you care about instead of converting marketing core counts into an unsupported score.