1922908 - Read-only storage textures should be allowed without a feature

Status: NEW

(Core :: Graphics: WebGPU, defect)

Description

[Jim Blandy :jimb]

The patch in bug 1922854 introduces a lot of failures like this:

TEST-UNEXPECTED-FAIL | /_mozilla/webgpu/cts/webgpu/compat/api/validation/render_pipeline/unsupported_wgsl/cts.https.html?q=webgpu:compat,api,validation,render_pipeline,unsupported_wgsl:unsupportedStorageTextureFormats,computePipeline:* | :format="rg32float";entryPoint="csWithStorageUsage";async=false - assert_unreached: 
  - EXCEPTION: Error: Unexpected validation error occurred: Unable to derive an implicit layout, caused by: Binding 0 entry is invalid, caused by: Read-write and read-only storage textures are not allowed by webgpu, they require the native only feature TEXTURE_ADAPTER_SPECIFIC_FORMAT_FEATURES
    TestFailedButDeviceReusable@https://web-platform.test:8443/_mozilla/webgpu/webgpu/util/device_pool.js:22:1
    attemptEndTestScope@https://web-platform.test:8443/_mozilla/webgpu/webgpu/util/device_pool.js:413:13

In this log, all the csWithStorageUsage cases are failing, regardless of the format and async variant.

The source code of the test that's failing seems to be here.

I wonder if this PR is related:
fix(wgpu): Raise validation error instead of panicking in get_bind_group_layout. #6280

Comment 1

[Jim Blandy :jimb]

Actually, it could also be related to #6328, the fix to phony assignments:
https://github.com/gfx-rs/wgpu/issues/6095#issuecomment-2365021257

From the test case, we can see that the csWithStorageUsage entry point has a phony assignment:

    const module = t.device.createShaderModule({
      code: `
        @group(0) @binding(0) var s: texture_storage_2d<${format}, read>;
        @compute @workgroup_size(1) fn csWithoutStorageUsage() {
        }
        @compute @workgroup_size(1) fn csWithStorageUsage() {
            _ = textureLoad(s, vec2u(0));
        }
      `,
    });

Before #6328, this phony assignment would have been removed entirely from the module by compaction. That removal was incorrect, because it affected the computation of the interface of a shader. Thus, Firefox previously considered csWithStorageUsage not to use the storage texture s; after the wgpu update, it does.

The failure is expected here:

    const isValid = !t.isCompatibility || entryPoint === 'csWithoutStorageUsage';
    t.doCreateComputePipelineTest(async, isValid, {
      layout: 'auto',
      compute: { module, entryPoint },
    });

Firefox does not support compatibility mode, so isValid is true, so doCreateComputePipelineTest is going to call expectValidationError and pass false for shouldError, directing it not to wrap the call to createComputePipeline in an error scope. This accounts for why the error is getting caught by attemptEndTestScope, as shown in the stack trace.

Comment 2

[Jim Blandy :jimb]

The error message from wgpu-core says, "Read-write and read-only storage textures are not allowed by webgpu, they require the native only feature TEXTURE_ADAPTER_SPECIFIC_FORMAT_FEATURES". But the test seems to think this should work on a non-compat WebGPU device.

My current guess: the WebGPU specification allows read-only storage textures, but wgpu hasn't been updated to permit them. However, Naga previously obscured the fact that csWithStorageUsage used the texture at all, so wgpu didn't complain, so the test passed for the wrong reason. Updating Naga made wgpu's missing read-only storage texture support detectable by the CTS, introducing the failure.

Comment 3

[Jim Blandy :jimb]

This is tracked upstream by wgpu#6372.