Add extension subgroup-size-control - #5578

Previews, as seen when this build job started (476428f):
WebGPU _{webgpu.idl | Explainer | Correspondence Reference}
WGSL _{grammar.js | wgsl.lalr.txt}

Should this PR also update the correspondence reference?

Should this PR also update the correspondence reference?

Done

PTAL, thanks!

I'll take a look at this today.

API LGTM. The last WGSL changes should still be reviewed by a WGSL person. And we still need tests before landing (that's tracked by the open comment, which will block the PR from landing).

Hi @kainino0x,

I've added all the tests to CTS (in gpuweb/cts#4640).

PTAL, thanks!

The CTS PR has been merged. @kainino0x, is this ready to land?

The CTS PR has been merged. @kainino0x, is this ready to land?

I was pushing to get this resolved, but I want to withdraw my pressure here. Based on the discussion above, it looks to me like this question is still very much unresolved. The web will have to deal with whatever we put in the spec forever, so it is very much worthwhile for us to spend a few weeks ensuring that we're doing the best we can do.

Hi @jimblandy @jrprice @kainino0x ,

I've landed the PR to test all valid subgroup sizes to the CTS. What else should I do to move this PR forward?

The only other thing was to run that test on a reasonable set of different hardware and make sure that our assertion (that it should pass almost everywhere) seems to be true. The Chromium bots probably test enough to cover that, but since the test just landed, it hasn't been run yet.

My personal summary of the decisions from the 2026-6-9 meeting:

• WebGPU should validate @subgroup_size attribute values to fall within the range established by GPUAdapterInfo's subgroupMinSize and subgroupMaxSize attributes.
• The CTS should test that a pipeline with a trivial compute shader can be created successfully with all powers of two in that range. (If an implementation advertises subgroup sizes that it can never actually support, the CTS should object to that.)
• For non-trivial compute shaders, the CTS should be prepared for specifying the subgroup size to cause shader compilation or pipeline creation to fail. That is, the CTS should not expect that, simply because a trivial shader can be compiled with a given @subgroup_size attribute value, more complicated shaders can also be compiled in that way.
• The CTS should treat subgroup sizes reported to fragment shaders that fall outside the subgroup{Min,Max}Size range as known errata on the older Intel GPUs where this occurs.

In the general case, WebGPU cannot promise that all subgroup sizes in the advertised subgroup{Min,Max}Size range are actually going to work for arbitrary shaders, since any shader compilation can fail due to factors outside our control, like register pressure. We can't even guarantee successful compilation of shaders when there are no @subgroup_size attributes in the picture at all. The CTS must content itself with verifying that trivial shaders, at least, can be compiled.