Skip to content

wave-intrinsic-helper-lane-hazard

Status: stub. The full-length analysis is queued for a v1.0.x patch release per ADR 0018, section 5, criterion #6. The companion rule page at docs/rules/wave-intrinsic-helper-lane-hazard.md contains the canonical detection logic + GPU reasoning.

TL;DR

The pixel-shader execution model on every modern GPU keeps the four lanes of a 2x2 quad co-resident even when some lanes are not part of a covered triangle. The non-covered lanes are called helper lanes; their results are discarded at the end, but they execute every instruction so that derivatives (ddx, ddy, implicit-LOD Sample) can read consistent coordinate values from all four lanes. This is essential for correct mip selection and gradient-based shading. After a discard, the affected lane likewise becomes a helper: it continues executing for derivative consistency but its colour and depth output are dropped.

What the rule fires on

Pixel shaders that call any cross-lane wave intrinsic (WaveActiveSum, WaveActiveMin, WavePrefixSum, WaveActiveBallot, WaveReadLaneAt, etc.) on a code path that is reachable after a discard or clip may have executed, when the entry point does not opt out of helper-lane participation via SM 6.6 IsHelperLane() guards. The same hazard applies to wave intrinsics placed inside loops where some quad lanes have early-exited: the inactive lanes are still tracked as helper lanes and may participate in cross-lane operations, contributing values that the algorithm did not intend to include.

See the What it detects section of the rule page for the full pattern definition.

Why it matters

The full GPU-mechanism analysis lives in the Why it matters on a GPU section of the companion rule page.

Examples

The bad / good code snippets are kept canonical on the rule page; see wave-intrinsic-helper-lane-hazard.md -> Examples.

See also


This is a v1.0-ship stub. Full analysis pending; track issue link TBD.

© 2026 NelCit — Apache-2.0 (code), CC-BY-4.0 (docs).