WGSL builtin textureSample compressed formats

[greggman]

I'm not sure these are needed or not but given we were testing so many other formats it seems like we should be testing compressed formats?

It does this by filling a compressed texture with random data. For compressed textures of type unorm or snorm this is fine. For float types this would fail since they random values might be large, Infinity, or NaN. We aren't converting from values to a compressed format. We're filling a buffer with binary random data and assuming the values that come out are in range.

After that, read that texture back to the GPU using a compute shader. This way we get WebGPU to decode the compressed texture to an uncompressed format.

Some places I got lost. I first put in the derivatives test and it passed. Then I put in non-derivatives test and it failed on srgb formats. This makes some sense I think because I was using only rgba32float as the format for pulling the data out of the texture.

That meant, when doing the software interpolation it was probably doing it wrong. I switched to using one of rgba8unorm, rgba8snorm or rgba8unorm-srgb as the format the texture is read back to TexelView as. I think ideally if I could have an rgba32float-srgb that would have been best but that format doesn't exist and I think hacking it into TexelView would have made TexelView's list of formats not a subset of WebGPU's

One thing I'm wondering is if I should combine the compressed and uncompressed tests. They're very similar and it wouldn't take too much work to add some small amount of if compressed {x} else {y} to consolidate them.

---

Requirements for PR author:

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

Requirements for reviewer sign-off:

• [x] Tests are properly located in the test tree.
• [x] Test descriptions allow a reader to "read only the test plans and evaluate coverage completeness", and accurately reflect the test code.
• [x] Tests provide complete coverage (including validation control cases). Missing coverage MUST be covered by TODOs.
• [x] Helpers and types promote readability and maintainability.

When landing this PR, be sure to make any necessary issue status updates.

[greggman]

note: only android is failing and it's failing on astc unorm formats with

no ulp representation for infinity/nan
Error: no ulp representation for infinity/nan

AFAICT this a bug on Android. The same tests pass on all other devices. If I understand correctly there are no invalid values for astc unorm formats. Further, the code is supposed to be predictable. The values put into the textures for testing should be the same across platforms. So it seems like this is either a GPU bug on those devices, a Dawn bug, or a JS bug (somehow it's producing NaN when it shouldn't)

I'm committing this for now. Revert if you have to. I'll also file a chrome bug

[greggman]

You're right, there are invalid inputs to astc. I can add a PR to filter those out. We'll have to either make an astc aware filler or leave them untested.