Characterizing Warp Divergence from Pascal to Blackwell
Abstract: Since Volta introduced Independent Thread Scheduling (ITS), NVIDIA GPUs have been widely assumed to handle warp divergence in a fixed manner. We test this assumption across Ampere, Hopper, and datacenter and consumer Blackwell GPUs, using pre-ITS Pascal as a baseline. Combining cycle-accurate microbenchmarks, hardware counters, and static analysis of compiler-generated SASS, we separate stable behavior from architectural change. Across all tested generations, divergent paths serialize linearly with the number of paths $k$, following $T(k) \approx sk$ with no super-linear reconvergence penalty. Warp execution efficiency falls as $32/k$, the penalty is independent of occupancy, and predication removes the serialization cost. The same behavior appears on Pascal, showing that this programmer-visible cost model predates ITS. The compiler-emitted reconvergence machinery, however, has changed substantially. Pascal uses a per-warp SSY/SYNC instruction stack, whereas later generations use barrier-register instructions. Deferred reconvergence beyond the immediate post-dominator falls from 29 cases on Ampere to 2 on Blackwell. Blackwell also introduces a two-tier convergence-barrier classification, uniform-branch instructions, and explicit partial-mask warp synchronization, none of which appear on Ampere or Hopper. Controlled bit-flip experiments indicate that the new barrier class is a static compiler classification with no observable runtime effect in our tests. Thus, divergence retains a stable and predictable performance cost even as NVIDIA's control-flow ISA and reconvergence mechanisms continue to evolve.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
What this paper is about (in simple terms)
This paper studies what happens inside NVIDIA graphics chips (GPUs) when a group of 32 tiny workers, called a warp, reaches an “if/else” in the code and not all workers choose the same side. This situation is called warp divergence. The authors test GPUs from several generations (Pascal, Ampere, Hopper, and Blackwell) to see:
- how much slower programs get when warps split up, and
- how the hardware and compiler bring the workers back together again.
Their big message: the cost you pay when a warp splits is simple and predictable—and it has stayed the same for years—while the behind-the-scenes machinery that manages “splitting and rejoining” has changed a lot.
The main questions the paper asks
- Does the time cost of warp divergence change across GPU generations (from Pascal to Blackwell)?
- Is the slowdown from divergence predictable?
- Can more activity on the GPU (higher occupancy) hide this slowdown?
- How exactly do newer GPUs and compilers tell threads when and where to rejoin after splitting?
- Did Independent Thread Scheduling (ITS), introduced in Volta, change the basic cost model, or just the internal plumbing?
How the researchers studied it (methods made easy)
Think of a warp as 32 students following the same lesson plan. If they reach a fork—some do Task A, others Task B—the class must do A and B separately, with the wrong students idle each time. Then they meet up and continue.
The authors used three approaches:
- Timed trials (microbenchmarks): They wrote tiny programs that force warps to split into 2, 4, 8, … up to 32 different paths, each path doing the same amount of work. They used a built-in stopwatch () to measure how many chip cycles these regions took. This shows the raw cost of divergence.
- Hardware counters: They read a GPU-provided meter that tells how many of the 32 threads are active, on average, for each instruction. If a warp splits into paths, they expect only $32/k$ threads to be active at a time. This checks that the timing really reflects divergence, not a compiler trick.
- Code disassembly (static analysis of SASS): They looked at the actual low-level instructions the compiler emits, especially the “reconvergence” instructions that tell threads where to regroup. Older GPUs used a simple stack (“remember this join point”), while newer ones use special barrier instructions. They compared how often and where those barriers are placed across generations.
Simple translations of a few terms:
- Warp: the 32 students.
- Divergence: students choose different tasks at a fork.
- Reconvergence: the point where everyone meets again.
- Predication: do both tasks but only keep the result you need—no real fork.
- Immediate post-dominator (IPDom): the very first step after the fork that every possible path must reach—the “natural meetup point.”
What they found (the key results)
- The slowdown is perfectly linear in the number of paths
- If a warp splits into paths that all do the same work, time scales like —basically times slower. There’s no extra “penalty” for rejoining, even for a full 32-way split.
- This was true on every tested generation: Ampere, Hopper, Blackwell (both server and consumer), and even on pre-ITS Pascal. So this predictable, linear cost existed before ITS and stayed stable after.
- Efficiency drops exactly as $32/k$
- The hardware counter shows the average active threads per instruction is almost exactly $32/k$ for . This confirms the linear timing isn’t a measurement trick—it’s real divergence.
- More occupancy doesn’t hide divergence
- Packing more work onto the GPU does not reduce the divergence penalty. Divergence makes you execute more instructions, and extra warps can hide waiting time (latency), not extra instruction count. Bottom line: a 32-way split still costs about 30×, no matter how busy the GPU is.
- Predication removes the split cost for small branches
- Rewriting a small “if/else” so both sides run and you just pick the right answer (predication) makes the cost drop from about 2× to about 1× for two-way forks. This advice works from Pascal through Blackwell.
- The “plumbing” for reconvergence changed a lot
- Pascal (pre-ITS) uses an instruction stack (#SSY/#SYNC) to remember where to meet.
- Post-Volta generations use explicit “barriers” (#BSSY/#BSYNC).
- Across generations, the compiler increasingly reconverges right at the IPDom (the natural earliest meeting point). “Deferred reconvergence” (meeting later than the IPDom) is common on Ampere, less on Hopper, and almost gone on Blackwell.
- Blackwell adds new control-flow features
- A two-tier barrier system: barriers marked .RECONVERGENT (the true final merge) vs .RELIABLE (early partial regroup points nested inside the true merge).
- Uniform branches (#BRA.U): used when the compiler can prove all 32 threads take the same path—no risk of divergence.
- Explicit partial-mask warp sync (#WARPSYNC): makes masked warp operations’ regrouping explicit.
- Bit-flip tests (manually changing the barrier “class” bits) showed these tags act as static labels the compiler uses; they didn’t change runtime behavior in the authors’ tests.
Why this matters
- For programmers and students of GPU performance:
- If a warp splits into equal paths, expect roughly slowdown, and average active threads drop to about $32/k$.
- This rule is stable from Pascal to Blackwell.
- More occupancy won’t save you; reduce divergence instead (e.g., by predication for small forks or reorganizing data so warps stay uniform).
- For tool builders and researchers:
- While the cost model is stable, the control-flow instructions and compiler strategies evolved. Tools that assume older ISA patterns may misread Blackwell code unless they handle the new barrier classes, uniform branches, and explicit partial-mask sync.
- For architects:
- Independent Thread Scheduling didn’t change the programmer-visible cost model of divergence. But the ISA and compiler reconvergence strategies continue to refine where and how threads meet, reducing deferred reconvergence and adding richer control-flow structure.
Simple takeaways
- Think of divergence like splitting a class into groups that must each use the same single classroom, one after another: it takes times as long.
- Getting more classes waiting in the hallway doesn’t speed up any single class’s turn.
- If the fork is tiny, just have everyone do both tasks quickly (predication) and move on together.
- Under the hood, the school’s bell schedule (the ISA/compilers) has changed its rules and signs, but the total time each split costs the class hasn’t.
Knowledge Gaps
Unresolved knowledge gaps, limitations, and open questions
The following list distills what remains missing, uncertain, or unexplored, framed so future work can act on it:
- Missing generations: No dynamic or static measurements on Volta (sm_70) or Turing (sm_75), leaving a gap between Pascal (pre-ITS) and Ampere in the claimed cross-generational invariance.
- Compiler vs. hardware causality: The observed shift toward IPDom reconvergence (and Blackwell’s two-tier barriers) is not isolated from compiler/ptxas version effects. Control for toolchain by:
- Recompiling the same PTX across multiple ptxas versions and driver releases.
- Running identical SASS on different GPUs via cubin targeting to attribute behavior to hardware vs. compiler.
- Balanced synthetic divergence only: Dynamic tests use balanced, equal-work, k-way splits. Unaddressed cases include:
- Skewed masks (e.g., 1/31 splits) and dynamically varying masks.
- Unbalanced work per path and nested/irregular divergence patterns.
- Memory–control-flow interaction: The cost model was measured with compute-heavy, cache-insensitive bodies. Unexplored interactions with:
- Coalescing, L1/L2 cache effects, TLB misses, and replay.
- Atomics and memory fences on divergent paths.
- Whether “linear serialization” and occupancy invariance persist under realistic memory behavior.
- Instruction-mix dependence: The per-path slope s is not characterized across instruction classes (e.g., SFU, tensor-core MMA, atomics, control-heavy code). Quantify s for diverse mixes and ILP levels.
- Path scheduling micro-mechanism: Paths “run in structural order to completion,” but the scheduler policy and its conditions (e.g., under long-latency stalls) are not identified. Test whether memory-induced stalls trigger finer interleaving across paths.
- Forward-progress scope: Forward-progress validation avoided unbounded peer-waits and could not reproduce classic SIMT-stack deadlock on Pascal. Validate on dedicated hardware with disabled watchdogs to:
- Demonstrate pre-ITS deadlock.
- Bound the latency of ITS forward progress under adversarial waits.
- Multi-warp effects: The runtime irrelevance of .RELIABLE and path-ordering observations were probed in single-warp settings. Test under:
- High SM residency with many divergent warps.
- MPS/MIG, preemption, and context switches (state save/restore of barrier registers).
- CTA- and cluster-level synchronization pressure.
- Barrier reliability semantics: Bit-flip tests were limited to sm_110 and simple kernels. Open questions:
- Do .RELIABLE/.RECONVERGENT bits influence hardware behavior under exceptions, traps, debugging/profiling, or warp-level preemption?
- Are there effects on sm_120 or future chips, or in multi-warp/CTA-wide patterns?
- WARPSYNC costs and semantics: Blackwell emits explicit WARPSYNC for partial masks, absent on prior gens. Quantify:
- Latency/throughput cost of WARPSYNC vs. implicit behavior.
- Corner-case correctness/performance with dynamic masks and cooperative-groups idioms.
- BRA.U (uniform branch) impact: The static presence of BRA.U is unquantified. Measure whether it improves fetch/issue efficiency, reduces divergence bookkeeping, or affects I-cache/BTB behavior.
- Reduced barrier-nesting cap (4→3 on Blackwell): Consequences for deeply nested divergence are unknown. Identify:
- When/where ptxas starts predicating or spilling barriers (BMOV) in real codes.
- The performance penalty of forced predication vs. barrier spilling.
- Normalization of per-path cost: The claim that s “tracks single-thread throughput” is qualitative. Establish a causal model by normalizing to per-thread IPC/issue width and correlating s with verified single-thread baselines.
- Counter validation on Pascal: Efficiency counters were unavailable; linearity inferred only from timing. Seek alternative access (older drivers/CUPTI admin mode) to validate 32/k on pre-ITS hardware.
- CTA-level synchronization within divergence: Interactions between divergence and syncthreads/syncwarp (beyond simple WARPSYNC) are untested. Probe correctness and cost under divergent regions with block- and cluster-level barriers.
- Code-footprint and I-cache effects: The study does not vary the instruction footprint per path. Test whether large, divergent code regions introduce additional fetch/ICache/BTB penalties beyond k× serialization.
- Reconvergence placement vs. PTX/source constructs: Mapping from high-level control flow and PTX directives to emitted BSSY/BSYNC classes is not characterized. Provide rules/heuristics that predict .RELIABLE vs. .RECONVERGENT placement.
- Robustness across optimization levels: Static findings are tied to one (unspecified) optimization level. Vary -O flags, inlining policies, and predication thresholds to quantify their impact on reconvergence strategy and divergence cost.
- Applicability to real applications: Microbenchmarks dominate. Validate linearity and occupancy invariance on end-to-end workloads (e.g., graph traversal, ray tracing, control-flow-heavy DL models) and report deviations.
- Energy/power implications: Only cycle costs are reported. Measure energy per instruction/path under divergence to assess architectural and algorithmic trade-offs.
- Exception/trap behavior in divergent regions: The impact of page faults, device-side assert, and floating-point exceptions on reconvergence and progress guarantees is unaddressed.
- Cross-vendor context: Findings are NVIDIA-specific. Comparative studies on AMD/Intel GPUs could disentangle SIMT-model fundamentals from vendor-specific ISA/compiler choices.
- Reproducibility artifacts: The kernel corpus, SASS dumps, and cubin patching scripts are not provided. Publishing them would enable independent verification and extension.
Practical Applications
Immediate Applications
Below are concrete ways the paper’s results can be used now across sectors, tools, and workflows.
- Production GPU kernel optimization playbook (software, AI/ML, graphics, HPC, finance)
- Actions:
- Treat k-way divergence as k× runtime inflation and 32/k warp efficiency; do not expect occupancy to hide it.
- Prefer predication for short/lightweight branches (replace if/else with masked computation).
- Reduce k by data reordering/bucketing so that warps process homogeneous cases.
- Instrument with Nsight Compute metric smsp__thread_inst_executed_per_inst_executed.ratio and add CI gates on “divergence budget.”
- Potential tools/products: “Warp Divergence Linter” for CUDA/Triton; Nsight panel/CI plugin that flags kernels with efficiency < threshold and suggests predication or bucketing.
- Assumptions/dependencies: Warp size 32; results measured on Pascal–Blackwell; kernels where memory effects do not dominate; requires Nsight/driver access for counters.
- Performance portability and modeling guidelines (software performance engineering, compilers, autotuners)
- Actions:
- Calibrate only the per-path slope s by architecture family; reuse the linear k× model across Ampere–Blackwell.
- Update autotuner cost models (e.g., TVM, Triton, XLA, CUTLASS) to treat divergence penalty as occupancy-invariant.
- Potential tools/products: “DivergenceCost” module in autotuners; Triton/MLIR pass that scores branch alternatives with T(k)=s·k.
- Assumptions/dependencies: Per-path cost s tracks single-thread throughput and may change between families; validate on target hardware.
- Compiler/codegen updates for Blackwell control-flow ISA (compilers, toolchains)
- Actions:
- Teach SASS/PTX backends and analyzers to parse and preserve BRA.U (uniform branch) and WARPSYNC (explicit partial-mask sync).
- Treat .RECONVERGENT/.RELIABLE barrier tags as static annotations (no observed runtime effect in tested regimes); maintain correctness when transforming control flow.
- Potential tools/products: LLVM NVPTX/NVC++ patches; SASS parsers that round-trip barrier-class bits; PTX intrinsics or attributes to hint uniform branches.
- Assumptions/dependencies: CUDA 13+ and Blackwell targets; future drivers could repurpose bits—keep tests in place.
- Accurate control-flow reconstruction and binary instrumentation (profilers, DBI frameworks)
- Actions:
- Update NVBit/SASSI-based tools to:
- Recognize BSSY/BSYNC/BREAK patterns, two-tier barriers, and BRA.U.
- Prefer immediate-post-dominator reconvergence and expect minimal deferred reconvergence on Blackwell.
- Potential tools/products: “sass-cfg-diff” tool to compare reconvergence placement across SM versions; NVBit plugins that annotate warp reconvergence episodes.
- Assumptions/dependencies: Access to nvdisasm/cuobjdump; correct handling of vendor-specific encodings.
- Real-time and embedded GPU planning (robotics, autonomous systems on Jetson AGX Thor)
- Actions:
- Use linear divergence cost to bound worst-case execution time (WCET) of control-heavy kernels; rely on forward progress and in-order completion of divergent paths absent contention.
- Potential workflows: Safety cases that include a “divergence budget” per warp; kernel acceptance criteria using measured s and maximal k.
- Assumptions/dependencies: WCET model assumes compute-bound segments; add margins if memory divergence or contention is significant.
- Procurement and capacity planning (HPC centers, enterprise IT)
- Actions:
- For divergence-dominated workloads, select across Ampere/Hopper/Blackwell primarily on single-thread throughput and memory/system features—not on divergent-control differences.
- Potential workflows: RFP language emphasizing per-path throughput over presumed “better divergence handling.”
- Assumptions/dependencies: Applies to NVIDIA GPUs in scope; validate on representative kernels.
- Education and team enablement (academia, industry training)
- Actions:
- Update curricula and internal guidelines: “Occupancy does not hide divergence,” “Predication first,” “Measure 32/k efficiency.”
- Potential materials: Lab exercises that replicate Figure-style microbenchmarks; code templates showing predication vs branching.
- Assumptions/dependencies: Access to at least one recent NVIDIA GPU and Nsight Compute.
- Regression testing for drivers/compilers (software QA)
- Actions:
- Add small divergence microbenchmarks to CI to detect non-linear cost regressions after driver or compiler updates.
- Potential workflows: “Linearity check” that fits T(k)=s·k+c for k∈{1,2,4,8,16,32}.
- Assumptions/dependencies: Stable clocks or use cycle counters (clock64); fix CUDA and toolchain versions for baselines.
Long-Term Applications
These opportunities need further research, scaling, or vendor support.
- Autonomic divergence mitigation in compilers and runtimes (software, AI compilers)
- Idea:
- Automatic branch-to-predication transforms guided by a learned cost model of s and branch body size.
- Data bucketing and warp-aware scheduling in JITs (Triton/TVM) to minimize k at runtime.
- Potential products: Triton pass that clusters tensor elements by branch outcome; MLIR dialect ops for “assume_uniform” with fallbacks.
- Assumptions/dependencies: Low-overhead data permutation; interplay with memory locality preserved.
- Cross-architecture control-flow standardization and IR annotations (compilers, standards)
- Idea:
- Standard IR attributes for “uniform branch,” “reconvergent,” and “reliable partial barrier,” portable across GPU vendors.
- Potential products: PTX/LLVM extensions; validation tools that check reconvergence placement against IPDom.
- Assumptions/dependencies: Community and vendor buy-in; mapping to non-NVIDIA ISAs.
- Next-generation simulators and analytical models (academia, EDA)
- Idea:
- Bake a validated, arch-invariant divergence kernel into Accel-Sim/GPGPU-Sim, including occupancy invariance and ordered path completion.
- Potential products: “Divergence module” releases; benchmark suites with divergence ground truth.
- Assumptions/dependencies: Continued validation on future architectures; inclusion of memory-divergence interplay.
- Sector-specialized kernels with divergence-aware data pipelines
- Healthcare/imaging: Pre-segment voxels into homogenous tiles to cut k before GPU kernels; integrate into DICOM-to-GPU ETL.
- Finance/risk: Monte Carlo path bucketing by barrier/knock-out state to run near-uniform warps; dynamic regrouping across timesteps.
- Energy/seismic: Ray/path clustering by geological layer transitions to reduce branch splits.
- Robotics: Control-law selection pre-pass that assigns warps per maneuver class in motion planning.
- Potential products: “Divergence-aware preprocessor” libraries that attach to existing pipelines.
- Assumptions/dependencies: Preprocessing cost must be amortized; data skew and dynamics may erode clustering.
- Debugging and visualization of reconvergence (tools ecosystem)
- Idea:
- A “warp timeline” viewer that shows active-mask evolution, barrier hits (RECONVERGENT vs RELIABLE), and efficiency over time.
- Potential products: Nsight plugin; standalone profiler with SASS overlay.
- Assumptions/dependencies: Access to low-level traces or hardware hook availability.
- Research on untested regimes and new controls (academia, vendors)
- Idea:
- Probe whether .RELIABLE gains runtime meaning under multi-warp contention, new schedulers, or future drivers; explore exposing programmer hints to steer reconvergence or interleaving.
- Potential outcomes: ISA proposals for opt-in early-partial reconvergence semantics; kernel attributes to bias scheduling of divergent paths.
- Assumptions/dependencies: Vendor collaboration; potential hardware/driver changes.
- Real-time certification methods using divergence bounds (safety-critical systems)
- Idea:
- Formal WCET proofs that integrate linear divergence and ordered-path execution; certification kits for GPU-accelerated autonomy.
- Potential products: Safety cases and tooling for ISO 26262/DO-178C contexts on embedded GPUs.
- Assumptions/dependencies: Tight control of memory effects and platform determinism; regulator acceptance.
- Policy and benchmarking guidance (standards bodies, HPC consortia)
- Idea:
- Require reporting of warp-efficiency and k-distribution in published GPU results; define divergence-aware benchmark kernels.
- Potential outcomes: Reproducibility checklists; procurement benchmarks that separate divergence from memory effects.
- Assumptions/dependencies: Community consensus; standardized tooling to collect metrics.
Notes on feasibility across all applications
- Results are empirical on specific NVIDIA GPUs (sm_61, sm_86, sm_90, sm_110, sm_120) and CUDA toolchains (CUDA 12.4–13). Future architectures/drivers may change details.
- The linear model isolates compute-side divergence; memory divergence and synchronization can dominate in real workloads—validate in context.
- The .RELIABLE barrier field showed no runtime effect in single-warp tests; multi-warp/driver interactions were not exhaustively explored.
- Some applications require access to SASS/disassembly tools (nvdisasm, cuobjdump) and Nsight Compute metrics.
Glossary
- .RECONVERGENT: Blackwell barrier modifier denoting the true post-dominator merge that all lanes must reach; contrasted with a breakable early barrier. "a previously undocumented .RELIABLE class distinct from .RECONVERGENT, encoded in a 2-bit field"
- .RELIABLE: Blackwell barrier modifier marking an early, partial reconvergence that some lanes may exit via BREAK. "a previously undocumented .RELIABLE class distinct from .RECONVERGENT, encoded in a 2-bit field"
- Active mask: The per-warp bitmask indicating which lanes are currently active for an instruction. "A warp executes one instruction at a time across an active mask of up to 32 lanes."
- Barrier class: An ISA-encoded categorization of convergence barriers (e.g., .RECONVERGENT vs .RELIABLE) used by the compiler. "(.RECONVERGENT vs.\ .RELIABLE, a 2-bit barrier class)"
- Barrier nesting depth: The maximum number of simultaneously live reconvergence barriers a compiler/ISA supports. "Blackwell caps the live reconvergence-barrier nesting depth at $3$ versus $4$ on older parts"
- Barrier registers: Explicit architectural registers used to manage reconvergence instead of a hardware stack. "bare barrier registers (Ampere, Hopper)"
- BMOV: A SASS instruction used to spill barrier state when exceeding available barrier registers. "Across all generations we never observe the #1{BMOV} barrier-spill instruction"
- BRA.U: A SASS uniform-branch instruction used when the compiler proves a branch is non-divergent. "Blackwell emits a uniform-branch instruction #1{BRA.U}, predicated on a uniform datapath register"
- BREAK: A SASS control-flow instruction that allows early exit from a .RELIABLE barrier region. "The #1{BREAK} instruction is encoding-restricted to the .RELIABLE class"
- BSSY: A SASS instruction that establishes a reconvergence barrier at a given program counter. "#1{BSSY} establishes a reconvergence barrier at a target PC, and"
- BSYNC: A SASS instruction that waits for threads to arrive at a previously established barrier. "#1{BSYNC} waits on it rather than relying on an implicit hardware stack"
- Convergence barrier: An explicit control-flow mechanism marking where divergent paths should rejoin. "Blackwell additionally introduces a two-tier convergence barrier"
- Control-flow divergence: When threads in a warp follow different paths, reducing SIMD efficiency. "saying almost nothing about control-flow divergence"
- Deferred reconvergence: Reconverging later than the immediate post-dominator, often due to loops or unrolling. "the deferred reconvergence that classical SIMT-stack hardware relied on, collapses from $29$ cases on Ampere to $2$ on Blackwell"
- Forward progress: A scheduling guarantee that each thread will continue to make progress and not deadlock. "ITS guarantees forward progress"
- Hardware performance counters: On-chip counters exposed to profiling tools to measure events like active threads per instruction. "hardware performance counters"
- Immediate post-dominator (IPDom): The earliest instruction that all paths after a branch must reach; classic reconvergence point. "threads back together at the immediate post-dominator (IPDom) of each branch"
- Independent Thread Scheduling (ITS): A GPU execution model giving each thread its own PC and call stack, enabling independent scheduling. "Independent Thread Scheduling (ITS)"
- Instruction-issue cost: The performance penalty attributable to issuing more instructions, not merely latency. "because it is an instruction-issue cost that additional resident warps cannot hide"
- Nsight Compute metric smsp__thread_inst_executed_per_inst_executed.ratio: A profiler metric measuring average active threads per issued warp-instruction. "the Nsight Compute metric smsp__thread_inst_executed_per_\allowbreakinst_executed.ratio"
- Occupancy: The number of active warps per SM relative to the hardware maximum; affects latency hiding. "while occupancy hides latency rather than issue count"
- Occupancy-invariant: A property whose cost does not change with the number of resident warps. "the divergence penalty is occupancy-invariant"
- Per-lane mask: A predicate mask that enables executing both sides of a branch with inactive lanes masked off. "under a per-lane mask with the full warp active"
- Predication: Replacing a control-flow branch with predicated instructions so both paths execute under masks, avoiding divergence. "the compiler may predicate a short or simple branch"
- Reconvergence: The act of merging divergent execution paths back into a single path. "and must eventually reconverge them"
- Reconvergence stack: A per-warp hardware stack (pre-ITS) that pushes/pops reconvergence points at control-flow joins. "pre-ITS part still uses the literal #1{SSY}/#1{SYNC} instruction stack"
- SASS: NVIDIA’s proprietary binary ISA executed by GPUs. "NVIDIA GPUs execute a proprietary binary ISA (SASS)."
- Scheduling control word: Per-instruction metadata encoding stalls, yield, dependencies, and operand reuse hints. "carrying a compiler-assigned scheduling control word encoding a stall count, a yield hint, scoreboard dependencies, and a reuse cache"
- Scoreboard dependencies: Hardware-tracked read/write hazards that gate instruction issue until operands are ready. "scoreboard dependencies"
- SIMT: Single-Instruction, Multiple-Thread execution model where a warp executes one instruction across multiple threads. "The single-instruction, multiple-thread (SIMT) execution model"
- SM cycle counter: A per-SM timer used for cycle-accurate measurements in kernels. "the #1{clock64()} SM cycle counter"
- Uniform branch: A branch whose condition is the same for all threads in a warp, thus non-divergent. "a uniform-branch instruction #1{BRA.U}, predicated on a uniform datapath register"
- Uniform datapath register: A register value known to be identical across all lanes, enabling uniform control-flow decisions. "predicated on a uniform datapath register"
- WARPSYNC: A SASS instruction that enforces warp-level synchronization under partial masks on Blackwell. "an explicit #1{WARPSYNC} on Blackwell"
- Warp: A group of 32 threads that execute in lockstep under SIMT on NVIDIA GPUs. "groups 32 threads into a warp"
- Warp execution efficiency: The average number of active threads per issued warp-instruction (32 when fully converged). "We measure warp execution efficiency with the Nsight Compute metric"
Collections
Sign up for free to add this paper to one or more collections.