fix: emit dimension-correct HLSL texture sample offsets

[mvanhorn]

Connections

• Fixes Invalid HLSL for textureSampleLevel of 3d texture with offset #9717.

Summary

The HLSL backend wrapped every image-sampling offset in int2(...) as a DXC overload-resolution workaround. For a textureSampleLevel call on other-dimensioned sampled textures, that's the wrong type. For example, with 3D textures, the writer emitted a nested int2(int3(...)) expression, which fails to compile.

This makes the constructor follow the offset expression's own dimension, emitting int, int2, or int3 as appropriate, while keeping the explicit-constructor workaround DXC needs.

Testing

• Added a wgsl-9717-texture-sample-level-offset.hlsl snapshot test that emits checks for all dimensions of texture with textureSampleLevel.

Squash or Rebase?

Rebase.

Checklist

• I self-reviewed and fully understand this PR.
• WebGPU implementations built with wgpu may be affected behaviorally.
• Tests demonstrate the validation and altered logic works.
• CHANGELOG.md entries for the user-facing effects of this change are present.
• The PR is minimal, and doesn't make sense to land as multiple PRs.
• Commits are logically scoped and individually reviewable.
• The PR description has enough context to understand the motivation and solution implemented.

[ErichDonGubler]

This looks like a good start, and I like the snapshot test. There are a few things that still need to happen, though, before I'd approve this:

• Handle the feedback I left as individual conversations in the overall diff.
• The OP is verbose to the point of hurting communication (LLM output?), so I edited it down to the useful bits.
• The issue was motivated by CTS tests, and we should prove we're solving it with the same. Please add some CTS test coverage, preferably for all dimensionalities.

LMK if you need anything else!

[mvanhorn]

384870e covers all of it.

The three inline notes: vector_size_and_scalar() replaces the hand-rolled match, debug_assert_eq! is now assert_eq!, and the DXC issue comment is hoisted above the block it explains. CHANGELOG takes your wording, scoped to non-2D rather than just 3D.

On CTS: added the sampled_1d_coords and sampled_3d_coords execution selectors to cts_runner/test.lst, which are the non-2D dimensionalities whose offset constructor was wrong. Locally sampled_3d_coords is 3357 pass / 0 fail and sampled_1d_coords is 972 pass / 0 fail.

Worth being precise about what that does and does not show: I am on macOS, so those ran on Metal and cannot exercise the HLSL backend this fix touches. The CI matrix includes Windows x86_64, so landing these selectors is what actually puts the fix under CTS on dx12. The naga snapshot test remains the direct check on the generated HLSL.

One thing I found while there and did not touch: sampled_array_2d_coords fails locally on Metal for every case including offset=false, at depthOrArrayLayers=8 while 1 passes. It is unrelated to this change, so I left it out of test.lst rather than adding a known-failing selector. Happy to file it separately if that is useful.

Full naga suite: 216 pass, 0 fail, with clippy clean.

[ErichDonGubler]

Okay, this is looking good. However, I just noticed another problem that means we can't merge the current test coverage. 🫠 CTS test times for Other on Windows exploded, going from ~20m to ~3 hours.

We need to fix this, but I don't want to hold up this fix for that. Let's punt that to another issue/PR where we figure that out: #9974

CC @gfx-rs/wgpu ☝🏻

[ErichDonGubler]

Approving because of removed CTS coverage. Sigh. 🫠