Add declaration tests for WGSL immediate variables by shaoboyan091 · Pull Request #4661 · gpuweb/cts

shaoboyan091 · 2026-06-11T04:39:18Z

Adds a focused declaration suite for var<immediate>.

The new tests cover accepted scalar, vector, matrix, and struct store types, rejected store types, module-scope-only declarations, rejection of binding attributes, rejection of explicit access modes, and the one-immediate-variable-per-entry-point rule.

It also threads immediate through the existing declaration tests so the generic address space coverage checks the same declaration access rules as storage, uniform, private, workgroup, and function variables. The context-dependent resolution table now recognizes immediate_address_space as a language feature name.

Notes for reviewers:

Tests skip on the immediate_address_space WGSL language feature, so they run only where the requires immediate_address_space; shaders can compile (not merely where the immediate API surface is exposed).
f16/vec3h are treated as valid immediate store types (host-shareable and constructible, gated on shader-f16), consistent with how uniform accepts them.

Issue: #

Requirements for PR author:

All missing test coverage is tracked with "TODO" or .unimplemented().
New helpers are /** documented */ and new helper files are found in helper_index.txt.
Test behaves as expected in a WebGPU implementation. (If not passing, explain above.)
Test have be tested with compatibility mode validation enabled and behave as expected. (If not passing, explain above.)

Requirements for reviewer sign-off:

Tests are properly located.
Test descriptions are accurate and complete.
Tests provide complete coverage (including validation control cases). Missing coverage MUST be covered by TODOs.
Tests avoid over-parameterization (see case count report).

github-actions · 2026-06-11T04:47:25Z

Results for build job (at 5e77072):

-webgpu:shader,validation,decl,context_dependent_resolution:language_names:* - 4 cases, 12 subcases (~3/case)
+webgpu:shader,validation,decl,context_dependent_resolution:language_names:* - 5 cases, 15 subcases (~3/case)
+webgpu:shader,validation,decl,immediate:store_type,valid:* - 10 cases, 10 subcases (~1/case)
+webgpu:shader,validation,decl,immediate:store_type,invalid:* - 11 cases, 11 subcases (~1/case)
+webgpu:shader,validation,decl,immediate:scope:* - 2 cases, 2 subcases (~1/case)
+webgpu:shader,validation,decl,immediate:binding_attributes:* - 4 cases, 4 subcases (~1/case)
+webgpu:shader,validation,decl,immediate:access_mode:* - 4 cases, 4 subcases (~1/case)
+webgpu:shader,validation,decl,immediate:entry_point_interface:* - 5 cases, 5 subcases (~1/case)
+webgpu:shader,validation,decl,immediate:pointers:* - 8 cases, 8 subcases (~1/case)
-webgpu:shader,validation,decl,var:module_scope_types:* - 406 cases, 406 subcases (~1/case)
+webgpu:shader,validation,decl,var:module_scope_types:* - 464 cases, 464 subcases (~1/case)
-webgpu:shader,validation,decl,var:binding_point_on_non_resources:* - 8 cases, 8 subcases (~1/case)
+webgpu:shader,validation,decl,var:binding_point_on_non_resources:* - 12 cases, 12 subcases (~1/case)
-webgpu:shader,validation,decl,var:address_space_access_mode:* - 40 cases, 40 subcases (~1/case)
+webgpu:shader,validation,decl,var:address_space_access_mode:* - 48 cases, 48 subcases (~1/case)
-TOTAL: 283229 cases, 2325040 subcases
+TOTAL: 283344 cases, 2325157 subcases

This patch adds a focused declaration suite for `var<immediate>`. The new tests cover accepted scalar, vector, matrix, and struct store types, rejected store types, module-scope-only declarations, rejection of binding attributes, rejection of explicit access modes, and the one-immediate-variable-per-entry-point rule. It also threads `immediate` through the existing declaration tests so the generic address space coverage checks the same declaration access rules as storage, uniform, private, workgroup, and function variables. The context-dependent resolution table now recognizes `immediate_address_space` as a language feature name.

shaoboyan091 · 2026-06-11T07:03:10Z

@jrprice PTAL, catch a potential "issue" in chrome canary, it seems canary supported fixed array in immediate address space but the spec said it shouldn't.

Fixed array could be supported in implementation but it doesn't be discussed in community yet.

shaoboyan091 · 2026-06-15T09:47:39Z

@jrprice softly ping for reviewing, thanks!

dj2 · 2026-06-15T15:29:04Z

+  u32: { enable: ``, prelude: ``, type: `u32` },
+  i32: { enable: ``, prelude: ``, type: `i32` },
+  f32: { enable: ``, prelude: ``, type: `f32` },
+  f16: { enable: `enable f16;`, prelude: ``, type: `f16` },


Why is f16 here if it isn't supported yet?

The spec text we landed seems to allow f16, but I can't find any discussion that says that this was intentional. That said it's probably easy enough to support since in Tint at least we just decompose the buffers anyway. I've asked internally whether this is expected to be supported or not.

@shaoboyan091 do we already have CTS execution/operation tests that cover f16 in immediate, to make sure they actually work?

TBH, This is from this https://github.com/gpuweb/cts/blob/main/src/webgpu/api/operation/command_buffer/programmable/immediate.spec.ts#L410
But I suspect this is due to API limit #4297 and shouldn't affect decl test here. Let me change the code and try.

After adding f16 support, local try report " error: using 'f16' in 'immediate' address space is not implemented yet" And I find in dawn part. https://source.chromium.org/chromium/chromium/src/+/main:third_party/dawn/src/tint/lang/wgsl/resolver/address_space_validation_test.cc;drc=874b76badc54f1ece2369347db39ee5406678021;l=756. That's a bit surprise me.

I noticed the spec PR gpuweb/gpuweb#6297 about restrict f16 support, is this because we don't have implementation to verify the ability?

dj2 · 2026-06-15T15:32:41Z

+    t.expectCompileResult(false, wgsl);
+  });
+
+g.test('scope')


Given the test is mostly predicated on the module vs function can we just make 2 tests?

Yeah the code paths are too different for module-scope to be acting as a control-case here.

Suggest dropping module-scope since it's covered by other tests, and just having function scope where the control case uses the function address space.

The WGSL spec allows f16 in the immediate address space: f16 is a host-shareable constructible scalar, and immediate store types only exclude arrays and structures containing arrays. Remove the f16 immediate skip so the validation tests assert the spec-correct result (f16 immediate compiles). An implementation that rejects f16 immediate is non-conformant and will be flagged by these tests.

The WGSL spec is restricting f16 in the immediate address space (gpuweb/gpuweb#6297), so move f16 and vec3h to the rejected immediate store types and exclude f16 types from the accepted immediate store types in the shared module-scope coverage. Simplify the scope test to declare the variable at function scope for both cases and vary only the address space, using the function address space as the control. Module-scope validity is already covered by the module_scope_types test.

dj2 · 2026-06-17T18:29:50Z

Discussing internally, we think f16 should be supportable, so it isn't an oversight, but just a bug in Tint. So, we should set the CTS to have it as available, remove the skip and then file a bug to fix the Tint code.

shaoboyan091 · 2026-06-18T01:20:57Z

Discussing internally, we think f16 should be supportable, so it isn't an oversight, but just a bug in Tint. So, we should set the CTS to have it as available, remove the skip and then file a bug to fix the Tint code.

Good to know this. F16 is important.

The WGSL spec allows f16 in the immediate address space, so f16 and vec3h are valid immediate store types and are expected to compile. No skip is added for implementations that reject f16 immediate data; an implementation that does so is non-conformant, and these tests flag it.

shaoboyan091 · 2026-06-22T05:55:48Z

@dj2 and @jrprice pls take a look at new commits which should address above comments.

shaoboyan091 force-pushed the pr/immediate-declaration-validation branch from 7a7b534 to a466dea Compare June 11, 2026 04:40

shaoboyan091 force-pushed the pr/immediate-declaration-validation branch from a466dea to a3c267f Compare June 11, 2026 06:48

shaoboyan091 requested a review from jrprice June 11, 2026 07:01

dj2 reviewed Jun 15, 2026

View reviewed changes

shaoboyan091 added 2 commits June 16, 2026 14:19

shaoboyan091 requested a review from dj2 June 22, 2026 05:55

Conversation

shaoboyan091 commented Jun 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Jun 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

shaoboyan091 commented Jun 11, 2026

Uh oh!

shaoboyan091 commented Jun 15, 2026

Uh oh!

dj2 Jun 15, 2026

Choose a reason for hiding this comment

Uh oh!

jrprice Jun 16, 2026

Choose a reason for hiding this comment

Uh oh!

shaoboyan091 Jun 16, 2026

Choose a reason for hiding this comment

Uh oh!

shaoboyan091 Jun 16, 2026

Choose a reason for hiding this comment

Uh oh!

shaoboyan091 Jun 17, 2026

Choose a reason for hiding this comment

Uh oh!

dj2 Jun 15, 2026

Choose a reason for hiding this comment

Uh oh!

jrprice Jun 16, 2026

Choose a reason for hiding this comment

Uh oh!

dj2 commented Jun 17, 2026

Uh oh!

shaoboyan091 commented Jun 18, 2026

Uh oh!

shaoboyan091 commented Jun 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

shaoboyan091 commented Jun 11, 2026 •

edited

Loading

github-actions Bot commented Jun 11, 2026 •

edited

Loading