WGSL’s March 10, 2026 Candidate Recommendation sharpens subgroups, barriers, and buffer layout for compute. Full breakdown.
What the Candidate Recommendation Clarifies
WGSL’s March 10, 2026 Candidate Recommendation tightens how compute shaders express three things that used to force careful reading of drafts and vendor notes: subgroups, barriers, and buffer layout. For anyone shipping GPU work through WebGPU, those three areas determine whether a kernel is correct under concurrent execution, whether it stays portable across implementations, and whether data in storage and uniform buffers lands where the shader expects it.
The practical effect is less ambiguity in the language rules, not a new programming model. You still dispatch workgroups, still reason about local and global memory, and still pay for every synchronization point you insert. The CR language makes the allowed patterns clearer so you can write those synchronizations and layouts once and trust the same structure more widely.
Subgroup Patterns Without Guesswork
Subgroups give you a smaller coordination unit than a full workgroup: shuffles, ballots, reductions, and broadcasts among lanes that run together. Useful patterns include reducing a tile of values before writing a single result, electing a leader lane to perform a shared memory load, and packing per-lane flags into a mask so the group can branch less often. The CR sharpening is about which operations are required, how inactive lanes behave, and how subgroup size relates to workgroup size—details that decide whether a clever reduction is portable or only works on one stack.
Prefer subgroup ops when the problem is naturally lane-local and you can tolerate implementation-defined subgroup size. Prefer workgroup shared memory plus barriers when every invocation in the group must see the same intermediate state. Mixing both is common: reduce within a subgroup, write partials to shared memory, barrier, then finish at the workgroup level. Document assumptions about active lanes and divergent control flow; a ballot or shuffle across a divergent branch is where correctness breaks first.
Barriers: Place Them Where Visibility Matters
Barriers exist so writes from one invocation become visible to others before later reads. In compute, the usual sequence is write shared (or device) memory, barrier with the right scope and memory semantics, then read. Too few barriers race; too many serialize work that could stay concurrent. Scope matters: a workgroup barrier does not order traffic between workgroups, and device-wide ordering still depends on how you structure dispatches and buffer usage across passes.
- Shared-memory producer/consumer: writers finish stores, barrier, readers load.
- Multi-phase tiles: barrier between phases when phase N+1 reuses the same shared slots.
- Avoid barriers around pure register work or when each invocation only touches private data.
When designing a kernel, list the memory regions each phase reads and writes. Insert a barrier only at the cut where a later phase needs an earlier phase’s stores. If two phases never share locations, skip the barrier and keep occupancy high.
Buffer Layout and Stable Compute Interfaces
Buffer layout rules decide how structures, arrays, and matrices sit in storage and uniform buffers. Misaligned fields, wrong stride assumptions, and host/device struct mismatches show up as silent wrong values rather than hard errors. Treat the host-side packing rules as part of the shader API: same field order, same alignment, same array stride, and explicit padding where the layout needs it. Prefer simple, tightly documented layouts for hot paths; push complex nesting into clearly sized blocks you control on both sides.
For multi-pass compute, keep buffer roles explicit—read-only inputs, read-write scratch, write-only outputs—and size dispatches from problem dimensions and workgroup shape, not from buffer length alone. Subgroups optimize within a group; barriers make mid-kernel sharing safe; buffer layout keeps the CPU and GPU agreeing on every byte. Together they are the core of reliable WGSL compute patterns under the Candidate Recommendation’s clearer rules.