wave-reduction-pixel-without-helper-attribute
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-reduction-pixel-without-helper-attribute.md contains the canonical detection logic + GPU reasoning.
TL;DR
By default, pixel-shader wave intrinsics exclude helper lanes from the active mask: a WaveActiveSum(x) that sees a partially-covered quad sums only the covered lanes and ignores the helpers. This is usually what the author wants — helpers don't contribute meaningful values for non-derivative work. But when the reduction's result then flows into a derivative operation, the derivative computation needs the full quad to be coherent: ddx(uniform) is zero only when all four quad lanes have the same value.
What the rule fires on
A pixel-shader entry that performs a wave reduction (WaveActiveSum, WaveActiveProduct, WaveActiveCountBits, WaveActiveBallot, etc.) whose result then flows into a derivative-bearing operation (ddx, ddy, an implicit-derivative texture sample) without [WaveOpsIncludeHelperLanes] declared on the entry. The Phase 4 data-flow analysis traces the reduction's output to the derivative operation; the rule fires when both occur and the attribute is absent.
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-reduction-pixel-without-helper-attribute.md -> Examples.
See also
- Rule page -- canonical reference + change log.
- wave-helper-lane overview -- broader context.
- ADR 0018 -- v1.0 readiness plan.
This is a v1.0-ship stub. Full analysis pending; track issue link TBD.