Allow lets of textures and samplers by alan-baker · Pull Request #5389 · gpuweb/gpuweb

alan-baker · 2025-10-15T15:33:32Z

Add a language feature, texture_and_sampler_let, that allows the effective value type of a let to be a texture or sampler type

github-actions · 2025-10-15T15:51:10Z

Previews, as seen when this build job started (c7a5176):
WebGPU _{webgpu.idl | Explainer | Correspondence Reference}
WGSL _{grammar.js | wgsl.lalr.txt}

dneto0

LGTM with wording nit.

wgsl/index.bs

mwyrzykowski

Using language extensions for non-HW features seems undesirable as it creates a shading language which is fragmented by feature support.

Is there any reason this needs to be a language extension?

mwyrzykowski

Removing my objection after discussion in the meeting.

It would be good that if we have at some point an official 'v2' WGSL version that all of these features are rolled-up in the v2 version and no longer reported to avoid this list from becoming increasingly long.

That is probably a separate topic however

jimblandy · 2025-10-21T19:07:30Z

minutes from WGSL committee meeting 2025-10-21

AB: Simple one, quality of life/nice to have. Will write CTS. Lower danger. Allows it as a transient value. Think the spec text is ready to go. We can wait for CTS, will just be validation tests really.
JB: Comment from MW on issue and raises some good points.
- MW: “It would be good that if we have at some point an official 'v2' WGSL version that all of these features are rolled-up in the v2 version and no longer reported to avoid this list from becoming increasingly long.”
JB: We are accumulating a bunch of language feature and would be nice to have some kind of way to say you don't need to worry about them anymore and they're just spec now.
AB: At risk of sounding strange, could have a language feature that implies other language features.
JP: Currently PR is scoped/named for textures/samples. Do we want other handle types like for bindless the bindless array or other handle types in the future?
AB: Not sure how to phrase that in the spec. I guess if they're coming later they can assume the language feature and add theemselves to the last? Maybe doesn't work, if they're an enable it's fine? Any type?
JP: Any handle type? It's the name, should be lets of handles instead of lets of texture/samplers? Then a future handle type could decide if it allows that
AB: So, any type instantiated in the handle address space, or anything that is opaque.
JP: Remembering where handle is used, was thinking address space
AB: That seems Ok, would be easy to change spec text to. Seems pretty restrictive, so seems safe. Going back to bufferView didn't want a let of buffer. If it's just opaque then answer is different.
DN: Should remember when we spec the bindless or arrays of textures to allow in lets. Kind of assume that we would allow from the get-go.
DS: For resource_binding don't think you'd want it, but maybe for binding_array?
JP: Let is just alias, so it all folds away anywhere. No technical reason why we couldn't. More a question of what users would want to do.
AB: Agree mostly. Thinking about buffer_view. A let of a buffer doesn't mean anything and you can't load it. You just couldn't use it anywhere. If you can't use it, why? it could be done. Doesn't make a difference to me. So, could write any type there I suppose. Feel like redesigning on the fly. If we want to go in this direction should wait and decide where we want to go.
DN: To confirm, did this fall out of bindless use cases?
AB: Yes. Also had other WESL requests where people wanted to be able to assign with conditional assignments.
JB: WESL wanted to return
AB: Yea didn't want to go that far yet. We couldn't do it in a meaningful way in the spec at the moment. But this seems nice for users. When we get to arrays of things will be nice to have.
DS: Seems in general this is the right thing, just with name being lets-of-handle. Gives us the flexibility we want.
JB: The default of the name should be inclusion.
AB: Do you want to phrased as anything in handle in to let or change feature name?
DS: I would just change the feature name and as we add things we can include them as it makes sense.
JB: Sounds like there is still some open questions to be worked out. Pretty detailed. General idea of introducing this relaxation has consensus. Need way to say what is covered by this generalization. Let folks think about it and come back in a later meeting.

mighdoll · 2025-10-21T19:10:15Z

As @alan-baker noted in the 2025.10.21 meeting, we see WESL requests to allow conditional compilation to cover textures and samplers (we showed some bevy examples at the last F2F). Lets on textures and samplers is a nice step toward supporting those cases in WGSL.

dneto0

LGTM, modulo bikeshedding the name (per committee discussion).

wgsl/index.bs

jimblandy · 2025-10-28T21:03:29Z

minutes from WGSL committee meeting 2025-10-28

“LGTM, modulo bikeshedding the name (per committee discussion).” - @dneto in the issue
JB: What kinds of things are we expecting to go into the handle address space? Heterogenous binding arrays.
DS: texel_buffer?
AB: Yes, it’d be a texture type, so already covered.
DS: So resource_binding and possibly binding_array.
JB: Brainstormed: resource_let, unrestricted_let, unrestricted_let_types, but not super hung up on this.
DS: resource_let would be interesting
AB: Sort of implies it allows more than it does. If you do a let of a storage buffer and attempt to invoke load rule, that’s not possible if it has a runtime array. So not really a resource let at that point, it’s a copy of the data. My other thought was that things that come in the future can make themselves or not. This feature just deals with things that are already in the spec that were not originally allowed.
DS: Makes sense to me, so the current name is fine.
JB: Yes, sounds OK. Everything else just goes in automatically.
Consensus: merge with current name

Refs gpuweb#5339 * Add a language feature, `texture_and_sampler_let`, that allows the effective value type of a let to be a texture or sampler type

Add support for the `texture_and_sampler_let` language feature. Spec PR: gpuweb/gpuweb#5389

The feature has landed in Dawn, just waiting for CTS and spec to land. Spec: gpuweb/gpuweb#5389 CTS: gpuweb/cts#4490 Fixed: 474082348 Change-Id: I4a1912b5878a7dcd5a9ad422544ccb654424fde0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7414637 Reviewed-by: Kai Ninomiya <[email protected]> Commit-Queue: dan sinclair <[email protected]> Auto-Submit: dan sinclair <[email protected]> Cr-Commit-Position: refs/heads/main@{#1567897}

alan-baker added this to the Milestone 2 milestone Oct 15, 2025

alan-baker requested review from dneto0 and mehmetoguzderin October 15, 2025 15:33

alan-baker added wgsl WebGPU Shading Language Issues language extension labels Oct 15, 2025

alan-baker added this to WGSL Oct 15, 2025

alan-baker moved this to Future agenda in WGSL Oct 15, 2025

dneto0 requested changes Oct 15, 2025

View reviewed changes

wgsl/index.bs Outdated Show resolved Hide resolved

alan-baker requested a review from dneto0 October 15, 2025 23:31

mehmetoguzderin approved these changes Oct 16, 2025

View reviewed changes

jimblandy moved this from Future agenda to Current agenda in WGSL Oct 20, 2025

mwyrzykowski requested changes Oct 21, 2025

View reviewed changes

mwyrzykowski approved these changes Oct 21, 2025

View reviewed changes

dneto0 approved these changes Oct 21, 2025

View reviewed changes

wgsl/index.bs Outdated Show resolved Hide resolved

wgsl/index.bs Show resolved Hide resolved

jimblandy moved this from Current agenda to Waiting on CTS in WGSL Oct 28, 2025

alan-baker force-pushed the texture-sampler-let branch from 3d56248 to 11bf024 Compare October 29, 2025 14:37

alan-baker mentioned this pull request Oct 29, 2025

Add CTS for texture_and_sampler_let language feature gpuweb/cts#4490

Merged

8 tasks

jimblandy mentioned this pull request Nov 19, 2025

Allow storing handle types in lets, maybe returning them from some functions. #5339

Closed

alan-baker added 4 commits January 9, 2026 16:28

Allow lets of textures and samplers

5b0dff5

Refs gpuweb#5339 * Add a language feature, `texture_and_sampler_let`, that allows the effective value type of a let to be a texture or sampler type

fix markup

82704f6

review feedback

4b81ac5

Update wgsl/index.bs

c7a5176

alan-baker force-pushed the texture-sampler-let branch from 11bf024 to c7a5176 Compare January 9, 2026 21:29

alan-baker enabled auto-merge (squash) January 9, 2026 21:29

alan-baker merged commit 9df11a5 into gpuweb:main Jan 9, 2026
4 checks passed

github-project-automation bot moved this from Waiting on CTS to Done in WGSL Jan 9, 2026

alan-baker deleted the texture-sampler-let branch January 10, 2026 20:06

dj2 mentioned this pull request Jan 12, 2026

Add texture_and_sampler_let language feature. webgpu-native/webgpu-headers#578

Merged

Kangz pushed a commit to webgpu-native/webgpu-headers that referenced this pull request Jan 12, 2026

Add texture_and_sampler_let language feature. (#578)

354d226

Add support for the `texture_and_sampler_let` language feature. Spec PR: gpuweb/gpuweb#5389

ErichDonGubler mentioned this pull request Jan 14, 2026

let assignment of textures and samplers in WGSL is not allowed, but should be gfx-rs/wgpu#8872

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow lets of textures and samplers#5389

Allow lets of textures and samplers#5389
alan-baker merged 4 commits intogpuweb:mainfrom
alan-baker:texture-sampler-let

alan-baker commented Oct 15, 2025

Uh oh!

github-actions bot commented Oct 15, 2025 •

edited

Loading

Uh oh!

dneto0 left a comment

Uh oh!

Uh oh!

mwyrzykowski left a comment

Uh oh!

mwyrzykowski left a comment •

edited

Loading

Uh oh!

jimblandy commented Oct 21, 2025

Uh oh!

mighdoll commented Oct 21, 2025

Uh oh!

dneto0 left a comment

Uh oh!

Uh oh!

Uh oh!

jimblandy commented Oct 28, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Conversation

alan-baker commented Oct 15, 2025

Uh oh!

github-actions bot commented Oct 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dneto0 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mwyrzykowski left a comment

Choose a reason for hiding this comment

Uh oh!

mwyrzykowski left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jimblandy commented Oct 21, 2025

Uh oh!

mighdoll commented Oct 21, 2025

Uh oh!

dneto0 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jimblandy commented Oct 28, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

github-actions bot commented Oct 15, 2025 •

edited

Loading

mwyrzykowski left a comment •

edited

Loading