Add texture-component-swizzle tests #4427

greggman · 2025-07-17T22:45:25Z

This is NOT ready to be merged. The extension first needs to be approved and @webgpu/types updated. Then the PR updated to removed the type hacks.

That said, @beaufortfrancois PTAL. What did I miss?

I don't think we want to add swizzle tests to all the texture builtins so I just tested 2, textureLoad and textureSampleLevel.
I only tested in a compute shader. I did not test in a vertex shader nor a fragment shader. Should I?
I only tested a few representative formats
Should swizzle in any form be disallowed without this extension or should it be allowed but only generate a validation error if it's not the identity? The test current requires it to be unset and expects a validation error.
Should we test textureGather. That one is hard and I think to do that I'd add it to the texture builtins if we want to test as it would be easier there. Is it supposed to swizzle?
Should swizzle generate a validation error on a depth texture binding. A depth texture binding only has 1 channel. (not to be confused with a 2d texture binding that has a depth texture bound. That is tested already in this PR)
Issue: Texture component swizzle 🥤 #4421

beaufortfrancois · 2025-07-18T06:31:55Z

I don't think we want to add swizzle tests to all the texture builtins so I just tested 2, textureLoad and textureSampleLevel.

FYI @Kangz suggested in https://dawn-review.googlesource.com/c/dawn/+/249434/comment/235838bf_c9a05964/ to test the various ways to use the view: Load/Fetch, Sampling, Gather, maybe the compare versions etc.

I only tested in a compute shader. I did not test in a vertex shader nor a fragment shader. Should I?

Yes. I initially also tested it in a compute shader but @Kangz strongly suggested [1] in https://dawn-review.googlesource.com/c/dawn/+/249434/comment/10136679_ddbd080c/ to not rely on the accuracy of the division, so I switched to a render pass in https://source.chromium.org/chromium/chromium/src/+/main:third_party/dawn/src/dawn/tests/end2end/TextureComponentSwizzleTests.cpp;drc=0416ce44ae6581e6b295b061c816ab5c70bf9cb3

I only tested a few representative formats

@Kangz explicitly asked to test with the whole zoo of textures in https://dawn-review.googlesource.com/c/dawn/+/249434/comment/235838bf_c9a05964/

Should swizzle in any form be disallowed without this extension or should it be allowed but only generate a validation error if it's not the identity? The test current requires it to be unset and expects a validation error.

I've opened gpuweb/gpuweb#5252 yesterday to figure this out.

Should we test textureGather. That one is hard and I think to do that I'd add it to the texture builtins if we want to test as it would be easier there. Is it supposed to swizzle?

See [1]

Should swizzle generate a validation error on a depth texture binding. A depth texture binding only has 1 channel. (not to be confused with a 2d texture binding that has a depth texture bound. That is tested already in this PR)

This is part of the "Open Questions" section. Without CTS tests to see how this would react, I would allow it for now and then see how it works in practice. We could also raise a validation error if G, B, or A swizzles are non default for depth texture binding.

Issue: Texture component swizzle 🥤 #4421

Note that I'll be on vacation next week.

beaufortfrancois · 2025-07-18T06:35:10Z

src/webgpu/api/validation/capability_checks/features/texture_component_swizzle.spec.ts

+      usage: GPUTextureUsage.COPY_DST | GPUTextureUsage.TEXTURE_BINDING,
+    });
+    t.expectValidationError(() => {
+      texture.createView({ swizzle: {} });


Depending on gpuweb/gpuweb#5252, we should also try a default swizzle.

greggman · 2025-07-18T08:55:44Z

I don't think we want to add swizzle tests to all the texture builtins so I just tested 2, textureLoad and textureSampleLevel.

FYI @Kangz suggested in https://dawn-review.googlesource.com/c/dawn/+/249434/comment/235838bf_c9a05964/ to test the various ways to use the view: Load/Fetch, Sampling, Gather, maybe the compare versions etc.

I think I'm missing someting. textureSampleCompare returns f32. There is nothing to swizzle. Further compare only allows depth textures (bindings with samplerType: 'depth' as input so this should arguably be a validation error as mentioned below.

I only tested in a compute shader. I did not test in a vertex shader nor a fragment shader. Should I?

Yes. I initially also tested it in a compute shader but @Kangz strongly suggested [1] in https://dawn-review.googlesource.com/c/dawn/+/249434/comment/10136679_ddbd080c/ to not rely on the accuracy of the division,

I don't know what that means. There is no division in my tests.

3> This is part of the "Open Questions" section. Without CTS tests to see how this would react, I would allow it for now and then see how it works in practice. We could also raise a validation error if G, B, or A swizzles are non default for depth texture binding.

Issue: Texture component swizzle 🥤 #4421

I think maybe I didn't get my point across

@group(0) @binding(0) var t1: texture_2d<f32>;  // this as float or unfilterered-float texture
@group(0) @binding(1) var t2: texture_depth;    // this is a depth texture

t1 above works and is tested already with depth formats.
t2 above only returns f32, not vec4f. There is nothing to swizzle. It doesn't return an R or G or B or A so swizzling makes no sense. So I asked, ignore the swizzle or generate a validation error if you try to provide one? I'd think generating a validation error is more inline with the rest of the API.

beaufortfrancois · 2025-07-18T10:31:40Z

I only tested in a compute shader. I did not test in a vertex shader nor a fragment shader. Should I?

Yes. I initially also tested it in a compute shader but @Kangz strongly suggested [1] in https://dawn-review.googlesource.com/c/dawn/+/249434/comment/10136679_ddbd080c/ to not rely on the accuracy of the division,

I don't know what that means. There is no division in my tests.

Since you use textureStore it may be fine actually. @Kangz will know more.

This is part of the "Open Questions" section. Without CTS tests to see how this would react, I would allow it for now and then see how it works in practice. We could also raise a validation error if G, B, or A swizzles are non default for depth texture binding.

Issue: Texture component swizzle 🥤 #4421

I think maybe I didn't get my point across
@group(0) @binding(0) var t1: texture_2d<f32>;  // this as float or unfilterered-float texture
@group(0) @binding(1) var t2: texture_depth;    // this is a depth texture
t1 above works and is tested already with depth formats.

t2 above only returns f32, not vec4f. There is nothing to swizzle. It doesn't return an R or G or B or A so swizzling makes no sense. So I asked, ignore the swizzle or generate a validation error if you try to provide one? I'd think generating a validation error is more inline with the rest of the API.

I assumed you meant texture_depth_2d in your WGSL example, not texture_depth. My understanding was that the first and unique value would be the R channel so that's why I would check only G, B, A swizzles. We could also generate a validation error if a swizzle is provided at all for texture_depth_* in the spec and relax this if developers actually use swizzle R for those depth textures.

Edit: This question was also asked in gpuweb/gpuweb#5217 (comment)

Kangz · 2025-07-18T12:27:49Z

The division I mentioned @beaufortfrancois was the one done by the fragment shader postfix to turn the vec4f into an rgba8unorm. This would still happen using textureStore I believe?

We should test the swizzle with the various builtins to make sure that it works in the various APIs. Right now the investigation was on what the APIs expose but they don't exhaustively say what happens with the whole zoo of texture features, so we need to validate that it is consistent across backends before exposing it.

greggman · 2025-07-21T23:27:56Z

The division I mentioned @beaufortfrancois was the one done by the fragment shader postfix to turn the vec4f into an rgba8unorm. This would still happen using textureStore I believe?

I'm using textureStore to a rgba32float, rgba32uint, or rgba32sint as appropriate. I'm not sure what division we are talking about here.

We should test the swizzle with the various builtins to make sure that it works in the various APIs. Right now the investigation was on what the APIs expose but they don't exhaustively say what happens with the whole zoo of texture features, so we need to validate that it is consistent across backends before exposing it.

Ok, but how far do we want to go? The current texture tests take ~1/3 of the CTS time. If I add swizzle tests to all possible combination of stuff that will go up by 2x to 3x

My current test already takes 8 minutes on an M1 Mac because of all the combinations.

all texture formats ⓧ
all builtins ⓧ
3 stages ⓧ
24 swizzles (undefined, identity, all red, all green, all blue, all alpha, all zero, all one, abgr, rot1, rot2, rot3, one in each slot (4), zero in each slot (4), undefined in each slot (4) ⓧ
3 alternates (this is to test that different swizzles on the same texture used in the same stage get different results)

I suppose we could test the 3 alternates as part of the 24 swizzles (so 27 total) instead of 24x3 which it is now. So that would lower it from 8 minutes to ~3 but then we need to add in a few more things that aren't being testing which will likely bring it back up to at least 5-6 mins.

It's currently only testing with 2d textures. It is not testing 1d, 3d, 2d-array, cube, cube-array (so adding those would be ~6x the combos). It's also not testing if mip settings affect it, nor layer settings, nor other sampler settings, nor re-intepretation (view is '-srgb'), and it's also not testing texture_depth_2d except for comparisons (that will ~double the tests)

Kangz · 2025-07-22T17:00:19Z

Yeah I hear you that it's easy to blow up the test time, maybe we can test all builtins + 27 swizzles on a few representative formats (1/2/4 channels?) and stencil / depth as 2d texture if that's a thing. IDK that all stages matter, but we definitely need fragment to cover all builtins. Do you have other ideas of things that are likely to interact and that need to be tested together?

greggman · 2025-07-29T23:52:46Z

I think this PR is ready for at least the current version of the spec proposal. It's only slow if debug=1 is passed. It's fast enough otherwise (~25 seconds for all tests combined on M1)

src/webgpu/api/validation/capability_checks/features/texture_component_swizzle.spec.ts

beaufortfrancois · 2025-07-30T12:38:51Z

...webgpu/api/validation/capability_checks/features/texture_component_swizzle_operation.spec.ts

@@ -0,0 +1,675 @@
+export const description = `
+Operational tests for the 'texture-component-swizzle' feature.


Should it live in api/operation instead of api/validation?

yea, maybe. Preference for location?

src/webgpu/api/operation/features/texture_component_swizzle.spec.ts ?

src/webgpu/api/operation/texture/texture_component_swizzle.spec.ts ?

other?

I don't have strong preferences to be honest. Both suggestions look good to me.

beaufortfrancois · 2025-07-30T12:48:55Z

I think this PR is ready for at least the current version of the spec proposal. It's only slow if debug=1 is passed. It's fast enough otherwise (~25 seconds for all tests combined on M1)

I'm looking forward to seeing all these "basic" tests pass on https://dawn-review.googlesource.com/c/dawn/+/255296. Thanks for starting that!

beaufortfrancois · 2025-08-05T18:24:30Z

@greggman FYI https://chromium-review.googlesource.com/c/chromium/src/+/6818591 has just been merged in Chromium. It should be in next Chrome Canary.

greggman · 2025-08-05T21:11:25Z

updated the tests for compat

beaufortfrancois · 2025-08-06T06:16:47Z

@greggman Shall we land these tests to see how different backends react in Chromium or are there more you want to add first?

greggman · 2025-08-06T16:22:56Z

I am not sure it's okay to check them in until the spec is approved. As is, they will start failing on other browsers immediately for not validating out non-identity swizzles.

greggman · 2025-08-06T16:28:21Z

Throwing out ideas, maybe the tests/spec should have 3 states

adapter.features does not have texture-component-swizzle

in this case, you can ignore the swizzle property. This is what browsers do today
adapter.features has texture-component-swizzle but you don't request it

in this case, you must validate the swizzle property is the identity if set
adapter.features has texture-component-swizzle and you request it

use the feature

I don't know if state 1 is desirable or if we're just going to update the spec to require swizzle validation even if the feature doesn't exist.

greggman · 2025-08-06T18:28:31Z

FYI, checking D3D12 NVidia, swizzle doesn't appear to work with stencil textures. Like {r: 'zero', g: 'zero', b: 'zero', a: 'zero' } doesn't return 0

From WG meeting: We should make the tests skip "must be identity" validation when the feature does not exist until the spec is approved. But we can check in the tests for when the feature exists. So I'll update the tests.

beaufortfrancois · 2025-08-07T07:31:06Z

FYI, checking D3D12 NVidia, swizzle doesn't appear to work with stencil textures. Like {r: 'zero', g: 'zero', b: 'zero', a: 'zero' } doesn't return 0

I've started 256414: [dawn][d3d12] Fix texture component swizzle for stencil formats to address this issue.

src/webgpu/shader/execution/expression/call/builtin/texture_utils.ts

src/webgpu/api/operation/texture_view/texture_component_swizzle.spec.ts

greggman

.

beaufortfrancois · 2025-08-12T07:40:56Z

After applying your fix, I get the following errors in https://ci.chromium.org/ui/p/chromium/builders/try/mac-arm64-dawn-rel/19727/test-results on macOS:

webgpu_cts_integration_test_base.py(419): AssertionError: webgpu:shader,execution,expression,call,builtin,textureLoad:multisampled: failed
  EXCEPTION: Error: Unexpected validation error occurred: [Texture (unlabeled 8x8 px, TextureFormat::Depth24PlusStencil8)] sample count (4) is not 1 when copying to or from a buffer.

for those tests:

shader,execution,expression,call,builtin,textureLoad:multisampled:stage="c";texture_type="texture_depth_multisampled_2d";format="depth24plus-stencil8"
shader,execution,expression,call,builtin,textureLoad:multisampled:stage="c";texture_type="texture_depth_multisampled_2d";format="depth24plus-stencil8"
shader,execution,expression,call,builtin,textureLoad:multisampled:stage="c";texture_type="texture_depth_multisampled_2d";format="depth32float-stencil8"
shader,execution,expression,call,builtin,textureLoad:multisampled:stage="c";texture_type="texture_depth_multisampled_2d";format="depth32float-stencil8"
shader,execution,expression,call,builtin,textureLoad:multisampled:stage="f";texture_type="texture_depth_multisampled_2d";format="depth24plus-stencil8"
shader,execution,expression,call,builtin,textureLoad:multisampled:stage="f";texture_type="texture_depth_multisampled_2d";format="depth24plus-stencil8"
shader,execution,expression,call,builtin,textureLoad:multisampled:stage="f";texture_type="texture_depth_multisampled_2d";format="depth32float-stencil8"
shader,execution,expression,call,builtin,textureLoad:multisampled:stage="f";texture_type="texture_depth_multisampled_2d";format="depth32float-stencil8"
shader,execution,expression,call,builtin,textureLoad:multisampled:stage="v";texture_type="texture_depth_multisampled_2d";format="depth24plus-stencil8"
shader,execution,expression,call,builtin,textureLoad:multisampled:stage="v";texture_type="texture_depth_multisampled_2d";format="depth24plus-stencil8"
shader,execution,expression,call,builtin,textureLoad:multisampled:stage="v";texture_type="texture_depth_multisampled_2d";format="depth32float-stencil8"
shader,execution,expression,call,builtin,textureLoad:multisampled:stage="v";texture_type="texture_depth_multisampled_2d";format="depth32float-stencil8"

beaufortfrancois · 2025-08-12T07:45:46Z

And I'm getting those on Windows as well (https://ci.chromium.org/ui/p/chromium/builders/try/win-dawn-rel/49419/test-results):

webgpu_cts_integration_test_base.py(419): AssertionError: webgpu:shader,execution,expression,call,builtin,texture_utils:readTextureToTexelViews: failed
  EXCEPTION: Error: Unexpected validation error occurred: The usage (TextureUsage::(CopyDst|TextureBinding)) of a multisampled texture doesn't include (TextureUsage::RenderAttachment).

for the following tests:

shader,execution,expression,call,builtin,texture_utils:readTextureToTexelViews:srcFormat="depth24plus-stencil8";texelViewFormat="rgba32float";viewDimension="2d";sampleCount=4
shader,execution,expression,call,builtin,texture_utils:readTextureToTexelViews:srcFormat="depth24plus";texelViewFormat="rgba32float";viewDimension="2d";sampleCount=4
shader,execution,expression,call,builtin,texture_utils:readTextureToTexelViews:srcFormat="r8sint";texelViewFormat="rgba32sint";viewDimension="2d";sampleCount=4
shader,execution,expression,call,builtin,texture_utils:readTextureToTexelViews:srcFormat="r8uint";texelViewFormat="rgba32uint";viewDimension="2d";sampleCount=4
shader,execution,expression,call,builtin,texture_utils:readTextureToTexelViews:srcFormat="r8unorm";texelViewFormat="rgba32float";viewDimension="2d";sampleCount=4
shader,execution,expression,call,builtin,texture_utils:readTextureToTexelViews:srcFormat="stencil8";texelViewFormat="stencil8";viewDimension="2d";sampleCount=4

beaufortfrancois · 2025-08-12T10:28:47Z

When applying the following fix (as in c805a27), I get rid of errors happening specifically in compatibility mode for depth textures. See results at https://dawn-review.googlesource.com/c/dawn/+/257115?checksResultsFilter=swizzle&tab=checks

    if (t.isCompatibility && isDepthTextureFormat(format)) {
      t.skipIf(
        func === 'textureLoad',
        'textureLoad can not be used with depth textures in compatibility mode'
      );
      t.skipIf(
        func === 'textureGather' || func === 'textureSample' || func === 'textureSampleLevel',
        'texture_depth_xx can not be used with non-comparison samplers in compatibility mode'
      );
    }

beaufortfrancois · 2025-08-12T12:10:22Z

src/webgpu/api/operation/texture_view/texture_component_swizzle.spec.ts

+
+TODO:
+* test stencil aspect of depth-stencil formats
+* test texture_depth_xxx with textureSample


I believe texture_depth_xx are actually tested with textureSample in this PR. Am I missing something?

@greggman gentle ping in case it was missed.

beaufortfrancois · 2025-08-12T13:58:28Z

And I'm getting those on Windows as well (https://ci.chromium.org/ui/p/chromium/builders/try/win-dawn-rel/49419/test-results):

webgpu_cts_integration_test_base.py(419): AssertionError: webgpu:shader,execution,expression,call,builtin,texture_utils:readTextureToTexelViews: failed
  EXCEPTION: Error: Unexpected validation error occurred: The usage (TextureUsage::(CopyDst|TextureBinding)) of a multisampled texture doesn't include (TextureUsage::RenderAttachment).

for the following tests:

shader,execution,expression,call,builtin,texture_utils:readTextureToTexelViews:srcFormat="depth24plus-stencil8";texelViewFormat="rgba32float";viewDimension="2d";sampleCount=4
shader,execution,expression,call,builtin,texture_utils:readTextureToTexelViews:srcFormat="depth24plus";texelViewFormat="rgba32float";viewDimension="2d";sampleCount=4
shader,execution,expression,call,builtin,texture_utils:readTextureToTexelViews:srcFormat="r8sint";texelViewFormat="rgba32sint";viewDimension="2d";sampleCount=4
shader,execution,expression,call,builtin,texture_utils:readTextureToTexelViews:srcFormat="r8uint";texelViewFormat="rgba32uint";viewDimension="2d";sampleCount=4
shader,execution,expression,call,builtin,texture_utils:readTextureToTexelViews:srcFormat="r8unorm";texelViewFormat="rgba32float";viewDimension="2d";sampleCount=4
shader,execution,expression,call,builtin,texture_utils:readTextureToTexelViews:srcFormat="stencil8";texelViewFormat="stencil8";viewDimension="2d";sampleCount=4

Luckily for us, applying the following fix 9a35732 in src/webgpu/shader/execution/expression/call/builtin/texture_utils.spec.ts makes them disappear:

-      usage: GPUTextureUsage.COPY_DST | GPUTextureUsage.TEXTURE_BINDING,
+      usage:
+        GPUTextureUsage.COPY_DST |
+        GPUTextureUsage.TEXTURE_BINDING |
+        GPUTextureUsage.RENDER_ATTACHMENT,

See https://dawn-review.googlesource.com/c/dawn/+/257174?tab=checks

EDIT: This is not working for all tests sadly as it now raises the following error:

  - EXCEPTION: Error: Unexpected validation error occurred: The texture usage (TextureUsage::(CopyDst|TextureBinding|RenderAttachment)) includes TextureUsage::RenderAttachment, which is incompatible with the texture dimension (TextureDimension::e1D).

Kangz · 2025-08-22T09:34:15Z

For swizzle, what matters is the usage of the view, not the usage of the texture. They are not necessarily the same because the view's usage can be a subset if GPUTextureViewDescriptor.usage is used.

greggman · 2025-08-22T18:00:16Z

For swizzle, what matters is the usage of the view, not the usage of the texture. They are not necessarily the same because the view's usage can be a subset if GPUTextureViewDescriptor.usage is used.

Oh! I think this is the first case I'm aware of where the view.usage is actually used? If not, I'm guessing other tests are checking texture.usage and not view.usage.

I updated the tests.

In other news though, my M1 Mac is having issues similar to when I tested the texture builtins. Everything is going fine and then suddenly some tests take forever. As it is, it gets into this state where a few tests timeout. It could be because it's a chromium build? I had one take 18 seconds. But, if I re-run the failing test it runs fast and passes.

greggman · 2025-08-22T20:22:47Z

checked, the speed issue is chromium. Canary doesn't have it.

greggman · 2025-08-26T07:36:11Z

I have a local change for expected depth to always be D,0,0,1. If you, @beaufortfrancois have an impl I can try it out.

greggman · 2025-08-26T22:54:36Z

Uploaded a version that expects D, 0, 0, 1 instead of D, ?, ?, ? when texture-component-swizzle is enabled.

I removed the 3 stages and am only testing the fragment stage. As for speed, with `debug` false it runs fast enough as is I think. About 25 seconds for all tests on M1 Mac. Note: One issue I ran into is the code that created textures would potentially create them with RENDER_ATTACHMENT if they needed to be rendered to to fill. A texture created with RENDER_ATTACHMENT can't be swizzled. My solution was to change the code that makes the texture such that, if the texture had RENDER_ATTACHMENT added, and it can be copied texture to texture, then make a copy without RENDER_ATTACHMENT Another issue I ran into and I'm not sure what solution is better, is testing depth-stencil formats. The existing code is not designed for that. All the depth-stencil formats are "unencodable". My solution was createTextureWithRandomDataAndGetTexelsForEachAspect that returns 2 sets of TexelViews, one for the depth aspect, another for the stencil aspec. It's possible, maybe we should make those formats encodable as Texels? I didn't chose that becuase depth-stencil has 2 types, f32 for depth, u32 for stencil. This seems like it would cause issues all over the place where code expects just one type. Another issue is depth24plus-stencil, the depth part is undefined. In the code, createTextureWithRandomDataAndGetTexelsForEachAspect on a depth format returns a TexelView with float data, not depth24plus data. I'm not sure all the encoders etc would handle this. So, like I mentioned above, my solution was to return 2 sets of TexelViews, one for the depth aspect and one for the stenci aspect. The code then choose one based on which aspect it's testing.

…omponent_swizzle.spec.ts Co-authored-by: François Beaufort <[email protected]>

Multisampled textures are required to have RENDER_ATTACHMENT usage. This was working by accident as `createTextureWithRandopmDataAndGetTexels` as adding the RENDER_ATTACHMENT usage. That usage addition is removed in this PR so the bug that it was not added here surfaced.

Originally the texture-utils made textures filled with random data based on a texture descriptor. If the texture format was depth or stencil they needed to render to the texture to get the data in since some formats do not support writeTexture nor copyBufferToTexture. To do this they needed to add RENDER_ATTACHMENT. But, texture-component-swizzle requires that RENDER_ATTACHMENT not be set. So, a check was added, if the texture created had texture.usage different than was originally requested then, make a new texture without those added usages and copy the texture into this new texture. 🎉 But, there were a few tests, like textureLoad multisample and texture_utils that happened to be passing by accident. They were testing multisample. Multisampled texture require RENDER_ATTACHMENT. They were not requesting a texture with RENDER_ATTACHMENT but were instead getting one by luck on the old path when RENDER_ATTACHMENT was magically added when needed. With the fix to remove RENDER_ATTACHMENT when it was not requested, these tests started failing. On top of that, the texture-component-swizzle tests test both the depth and stencil aspect of depth-stencil textures. Note that the WGSL builtin texture tests do not (yet?) do this. Adding the path to upload data for both depth AND stencil data broke because the copy above happened in the wrong place. The old broken path was 1. make texture with RENDER_ATTACHMENT 2. use copy texel data via render to fill depth data 3. make copy of texture without RENDER_ATTACHMENT 4. use copy texel data via render to fill stencil data (ERROR!) You can't fill the stencil via render if RENDER_ATTACHMENT is removed. The fix was to refactor so it's now effectively 1. make texture with RENDER_ATTACHMENT 2. use copy texel data via render to fill depth data 3. use copy texel data via render to fill stencil data 4. make copy of texture without RENDER_ATTACHMENT

1. `textureLoad` can not be uses with `texture_depth_2d` 2. `texture_depth_2d` can not be used with non-comparison samplers

The code was checking COPY_SRC when it shouldn't have

This was using texture.usage which was the wrong place to check. Switching to view.usage lets us test multisampled textures.

Note: this changes both the texture-component-swizzle tests and the general WGSL texture builtin tests so that if texture-component-swizzle is enabled, the WGSL texture builtin tests will expect D,0,0,1 instead of D,?,?,?

beaufortfrancois · 2025-09-03T09:19:09Z

I have a local change for expected depth to always be D,0,0,1. If you, @beaufortfrancois have an impl I can try it out.

I've updated https://dawn-review.googlesource.com/c/dawn/+/258594 based on your feedback (thanks!) and tried it locally on my machine. Let me know if that works as expected for you.

beaufortfrancois · 2025-09-03T10:36:16Z

@greggman And most importantly, does it work on all backends with this PR or do we need to update Dawn?

beaufortfrancois · 2025-09-03T10:49:09Z

@greggman As noted in https://github.com/gpuweb/gpuweb/blob/main/proposals/texture-component-swizzle.md#open-questions, shall we test whether texture component swizzle requires new validation rules if the view is multisampled?

It seems like you added tests for this. Are there new validation rules needed if the view is multisampled because some backends fail?

beaufortfrancois · 2025-09-03T15:32:30Z

@greggman And most importantly, does it work on all backends with this PR or do we need to update Dawn?

FYI I've started https://dawn-review.googlesource.com/c/dawn/+/260516?tab=checks but it's not finished yet as I'm writing this.

greggman · 2025-09-03T21:47:01Z

@greggman And most importantly, does it work on all backends with this PR or do we need to update Dawn?

FYI I've started https://dawn-review.googlesource.com/c/dawn/+/260516?tab=checks but it's not finished yet as I'm writing this.

These are failing on Mac but if download your CL and run locally everything passes. Are you sure https://dawn-review.googlesource.com/c/dawn/+/260516 incorporates your changes?

greggman · 2025-09-03T21:50:22Z

Oh, I guess they are only supposed to pass on M1 Mac, which they are. Intel and AMD Mac are buggy and this has not yet been implemented on other backends.

beaufortfrancois · 2025-09-04T09:06:14Z

These are failing on Mac but if download your CL and run locally everything passes. Are you sure https://dawn-review.googlesource.com/c/dawn/+/260516 incorporates your changes?

I'm unable to make this CTS roll with my CL changes sadly ;( Is this something you can try to see if Macs behave better?

This was added as RENDER_ATTACHMENT usage is incompatible with swizzle under the current spec. Unfortunately, copying a texture fails for depth textures on Mac Intel (because there is no test). It turns out the current spec only requires the texture view's usage not to have RENDER_ATTACHMENT, not the textures's, so this copy step is not needed. Removing it should let tests run on devices where copy is broken.

greggman force-pushed the texture-component-swizzle branch from d288b5e to a6bb46c Compare July 18, 2025 00:22

beaufortfrancois reviewed Jul 18, 2025

View reviewed changes

greggman force-pushed the texture-component-swizzle branch from a6bb46c to 8ca59a7 Compare July 21, 2025 23:22

greggman force-pushed the texture-component-swizzle branch from 8ca59a7 to d2e1f80 Compare July 29, 2025 23:13

beaufortfrancois reviewed Jul 30, 2025

View reviewed changes

src/webgpu/api/validation/capability_checks/features/texture_component_swizzle.spec.ts Outdated Show resolved Hide resolved

beaufortfrancois reviewed Jul 30, 2025

View reviewed changes

greggman force-pushed the texture-component-swizzle branch from 27727dc to 14ca630 Compare August 5, 2025 21:26

beaufortfrancois reviewed Aug 11, 2025

View reviewed changes

src/webgpu/shader/execution/expression/call/builtin/texture_utils.ts Outdated Show resolved Hide resolved

src/webgpu/api/operation/texture_view/texture_component_swizzle.spec.ts Outdated Show resolved Hide resolved

greggman force-pushed the texture-component-swizzle branch from bea9195 to 5a67cd5 Compare August 11, 2025 17:41

greggman commented Aug 11, 2025

View reviewed changes

beaufortfrancois reviewed Aug 12, 2025

View reviewed changes

greggman and others added 15 commits August 26, 2025 16:18

Update src/webgpu/api/validation/capability_checks/features/texture_c…

13c6d9b

…omponent_swizzle.spec.ts Co-authored-by: François Beaufort <[email protected]>

lint

72ce8d5

Move texture swizzle operation tests under api/operations

3c0be2a

skip non-matching swizzle operation tests in compat mode

42fd697

Test that mismatching swizzles cause validation error in compat mode

26975bd

Skip identity validation on browsers that have no yet implemented this

5144118

Add more compat limitation checks

e640510

1. `textureLoad` can not be uses with `texture_depth_2d` 2. `texture_depth_2d` can not be used with non-comparison samplers

remove todos

8ff8cf0

Check the correct usages when deciding to make a copy.

4cbc9da

The code was checking COPY_SRC when it shouldn't have

Switching to view.usage to validate bad usages

92fda5e

This was using texture.usage which was the wrong place to check. Switching to view.usage lets us test multisampled textures.

Test multisampled textures

b1e0c00

Expect depth textures to return D,0,0,1

76292d3

Note: this changes both the texture-component-swizzle tests and the general WGSL texture builtin tests so that if texture-component-swizzle is enabled, the WGSL texture builtin tests will expect D,0,0,1 instead of D,?,?,?

greggman force-pushed the texture-component-swizzle branch from 7e1d5df to 76292d3 Compare August 26, 2025 23:18

greggman force-pushed the texture-component-swizzle branch from a253882 to e1be9a2 Compare September 5, 2025 22:33

		@@ -0,0 +1,675 @@
		export const description = `
		Operational tests for the 'texture-component-swizzle' feature.

Add texture-component-swizzle tests #4427

Are you sure you want to change the base?

Add texture-component-swizzle tests #4427

Uh oh!

Conversation

greggman commented Jul 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

beaufortfrancois commented Jul 18, 2025

Uh oh!

beaufortfrancois Jul 18, 2025

Choose a reason for hiding this comment

Uh oh!

greggman commented Jul 18, 2025

Uh oh!

beaufortfrancois commented Jul 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kangz commented Jul 18, 2025

Uh oh!

greggman commented Jul 21, 2025

Uh oh!

Kangz commented Jul 22, 2025

Uh oh!

greggman commented Jul 29, 2025

Uh oh!

Uh oh!

beaufortfrancois Jul 30, 2025

Choose a reason for hiding this comment

Uh oh!

greggman Aug 1, 2025

Choose a reason for hiding this comment

Uh oh!

beaufortfrancois Aug 4, 2025

Choose a reason for hiding this comment

Uh oh!

beaufortfrancois commented Jul 30, 2025

Uh oh!

beaufortfrancois commented Aug 5, 2025

Uh oh!

greggman commented Aug 5, 2025

Uh oh!

beaufortfrancois commented Aug 6, 2025

Uh oh!

greggman commented Aug 6, 2025

Uh oh!

greggman commented Aug 6, 2025

Uh oh!

greggman commented Aug 6, 2025

Uh oh!

beaufortfrancois commented Aug 7, 2025

Uh oh!

Uh oh!

Uh oh!

greggman left a comment

Choose a reason for hiding this comment

Uh oh!

beaufortfrancois commented Aug 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

beaufortfrancois commented Aug 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

beaufortfrancois commented Aug 12, 2025

Uh oh!

beaufortfrancois Aug 12, 2025

Choose a reason for hiding this comment

Uh oh!

beaufortfrancois Aug 13, 2025

Choose a reason for hiding this comment

Uh oh!

beaufortfrancois commented Aug 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kangz commented Aug 22, 2025

Uh oh!

greggman commented Aug 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

greggman commented Aug 22, 2025

greggman commented Jul 17, 2025 •

edited

Loading

beaufortfrancois commented Jul 18, 2025 •

edited

Loading

beaufortfrancois commented Aug 12, 2025 •

edited

Loading

beaufortfrancois commented Aug 12, 2025 •

edited

Loading

beaufortfrancois commented Aug 12, 2025 •

edited

Loading

greggman commented Aug 22, 2025 •

edited

Loading

greggman commented Sep 3, 2025 •

edited

Loading