commit 61eae081fcac7b6da5b453842db1daad80f51e52
author Greggman <github@greggman.com> Tue Oct 14 18:52:36 2025
committer GitHub <noreply@github.com> Tue Oct 14 18:52:36 2025
tree 42dad78202bd9e7ffbbc33dc9be939b628983eb3
parent 4adb750084943d08f521f18cb36d85c792ff20ba

Add texture-component-swizzle tests (#4427)

* Add texture-component-swizzle tests

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.

* Move texture swizzle operation tests under api/operations
* skip non-matching swizzle operation tests in compat mode
* Test that mismatching swizzles cause validation error in compat mode
* Skip identity validation on browsers that have no yet implemented this
* Fix textureLoad test for multisampled textures

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.

* More adjustment for texture-utils issues.

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

* Add more compat limitation checks

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

* Check the correct usages when deciding to make a copy.

The code was checking COPY_SRC when it shouldn't have

* Switching to view.usage to validate bad usages

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

* Test multisampled textures

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

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,?,?,?

* Don't Copy Textures to remove RENDER_ATTACHMENT usage

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.

* Switch to WGSL syntax
* Add some swizzles that might mistakenly be accepted.
* Add copy support for r8snorm, rg8snorm, rgba8snorm
* remove invalid swizzle validation check
* add a few more invalid swizzles
* Refactor texture-component-swizzle validation tests.

Validation changed from createView time to createBindGroup,
beginRenderPass time.

Co-authored-by: François Beaufort <beaufort.francois@gmail.com>