GPU Web 2025‐10‐28 WGSL

Attendance

• Apple
  • Mike Wyrzykowski
• Google
  • Alan Baker
  • dan sinclair
  • David Neto
  • James Price
  • Kai Ninomiya
  • Peter McNeeley
  • Ryan Harrison
• Microsoft
  • Rafael Cintron
• Mozilla
  • Jim Blandy
• Mehmet Oguz Derin

⏳ Timeboxes (until XX:15)

Allow lets of textures and samplers #5389

• “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

⚖️ Discussions

Meta point: allow updates to proposals with lower bar of scrutiny than for modifying a shipped spec.. Agenda items for proposals is an opportunity for committee members to weigh in.

Explicit Bindgroup Layout Parameters #5353

• Direction looks good to everyone?
• Enough to start prototyping?
  • JimB: I’m looking forward to seeing what comes out of prototyping work on this feature. But just to make this clear in the record: until a feature has landed on the spec’s main branch, it’s still open to revision or removal. While implementation experience is valuable and of great interest to the committee, W3C members get ahead of the spec at their own risk; the committee gets to decide the spec’s contents.
  • DS: Still need to figure out how this maps to other languages. Until then, we can’t start prototyping.
• JB: This proposal has two goals:
  • Primary goal: to prepare for bindless, since we need these types for access to arrays of mixed-type resources.
  • Secondary goal: to fix problems with automatic pipeline layout generation. We have problems where the default pipeline layout algorithm is too naive: it doesn’t consider which samplers are applied to which textures, and without doing so it cannot always generate valid pipeline layouts. This can be fixed, but even if it is, the default pipeline layout algorithm may still be unable to generate some pipeline layouts; this is the problem #4956 and #4957 aim to address. If the goal is to use default layout generation to produce layouts that can be shared between multiple pipelines, it seems impossible that you could ever succeed at this by using an operation that only looks at one pipeline in isolation (e.g. createPipeline). We’re really talking about a relationship between a collection of pipelines, with a common interface that all of them subscribe to. I think this means that #4956 is inadequate, and #4957 is better because it makes pipeline layouts and bindgroup layouts explicit in the WGSL. One specific problem with #4956 is that the WGSL author has to make sure all resources needed by any of the pipelines are used, otherwise they won’t be mentioned in the layout. Another problem is, if somebody happens to use the old-style sampler or texture bindings, you’ll get the unknown versions of the types, and the default layout algorithm will behave the way it does now, and build you a pipeline layout that isn’t what you wanted. So unless you have a way of declaring what the desired layout is (e.g. #4957), you won’t get a feature that can be used in a way that we would like to use it. Small incremental changes are always nicer, but the change in #4956 will not actually be useful for what we need it for.
• JB: All that said, it seems that making default pipeline layout generation universal (#4956, #4957) is a subordinate goal, and supporting bindless is the main motivation for this issue.
• KN: Agree with the auto issue, so bug with making auto layouts being compatible with other auto layouts, might need an additional requirements, TBD. Not a huge deal either way because it’s deterministic. Would be good to have less confusing error messages.
• JB: Only #4957 avoids spooky-action-at-a-distance.
• MW: Are these changes are needed for bindless even if explicit used, or just for automatic layouts?
• DS: Even if explicit layouts are used, because we need to match value extracted from the buffer with the settings on the layout side.
• MW: Another concern: if we need to add these changes to WGSL for bindless, with most WGSL shaders being transpiled, then forcing people to annotate WGSL shaders seems like a potentially concerning roadmap for bindless. Don’t have a better proposal for this right now though, just a concern.
• AB: Current bindless proposal, what is the metadata that is getting tracked? Have to have a bunch of resource and information about them, is this not information that can be extracted dynamically so that we know? At what level are we OK with people doing certain things wrong? Bindless may open more undefined behavior, so should we just accept?
• DS: One place we wanted this: on API side set up a filtering sampler, Dawn creates buffer that says this slot is filtering, on WGSL side we pull sampler out and can check if it is used as a filtering sampler and if not we take a default filtering sampler out of buffer and use that instead. So matching against what the API-side says is in the layout. Don’t know what happens if you use a filtering sampler when you need an unfiltering sampler or vice versa.
• AB: Doesn’t work, but not sure how badly it doesn’t work. Is there anything else we can do in WGSL if they don’t match instead of having to predicate it.
• DN: The defaulting behavior is a dynamic check that will happen anyway?
• DS: Whenever you do getBinding<> we will check the metadata and use that to decide if we return the value or the default resource.
• JB: It’s not that we expect default to be correct, but at least it won’t invoke undefined behavior. So getBinding<> returns an optional value. What we’re offering right now is like a C++ maybe or a pointer that can be null, but hard to use correctly.
• DS: Even with an optional, we still need to know whether it’s filterable etc.
• JB: Yes, can’t escape that problem. But we would like to use best practices for how to present it.
• DN: Second what Mike said. Have to support use cases coming from bindless content. Should have an idea in mind about how this should work: “here’s an input shader, here’s what it turns into, and here’s what a tool will turn it into in WGSL”.
• DS: SPIR-V / Metal / Slang ?
• DN: Guessing a bunch of content out there is using HLSL to do this, so I would like to know what that would look like in WGSL. That would be informative.
• JB: Would be nice to have that in the bindless proposal doc. Also would be nice to have a reference to the Vulkan features we need to implement this.
• AB: Assume the specs says they must match, so doesn’t say what kind of undefined behavior you would get from it.
• JB: Right, like uniformity for derivatives, where we figured out it was just bad values.
• KN: I would guess that you would get uninitialized data from registers. No idea if it’s fully undefined behavior or not.

Proposal: fully explicit, non-exclusive "auto" layouts in WGSL (without createPipelineLayout) #4957

• JimB: How does this proposal related to #5353? Should we put off discussing it until #5353 is resolved?
  • ds: 5353 just provides more information to auto layouts, so it's related but doesn't solve the issue completely.

[Explicit BGL params] Verify the parameter conversions are valid #5355

• JB: Question about when we reconcile what is in WGSL with what is the bindgroup layout. So a filtering sampler in the bindgroup makes stricter requirements on the textures that it can be applied to, and thus it is not acceptable where the WGSL would require a non-filtering sampler, because that is fully general and can be applied to any texture. Now reading it, seems like the text is correct.
• DN: Reordered the table so the conversions go up and to the left, makes it much clearer.
• https://github.com/gpuweb/gpuweb/issues/5355#issuecomment-3457711139 comment:

	Sampler non_filtering	Sampler unknown	Sampler filtering
Texture float	Y	Y	Y
Texture unknown	Y	YA	YA
Texture unfilterable_float	Y	YA	N

[Explicit BGL params] Requirement for the unknown token #5356

• DS: Interesting question, do we want it to be spellable? Can’t spell void. Equivalent of not putting a value in. One argument is that it is more clear from the author’s perspective.
• JB: Was helpful to me to understand that classic sampler is equivalent to sampler<unknown>, so that made the spec clearer to me. We do have things like the handle address space, which are used in the spec but not spellable in WGSL.

[Explicit BGL params] Relax the function traceback rule? #5357

• JB: This is referring to the paragraph that says “if no filterable parameters are provided… auto layout algorithm will take care of them…”. It seemed to me that this might be a restriction that is stricter than what WGSL is doing right now. At the moment we can have a WGSL function that looks like this:

        fn twice(s: sampler, t: texture_2d<f32>) -> vec4<f32> {
            return sampleTexture(s, t, vec2(0,0)) * 2;
        }

• JB: This function can be applied to a sampler<non_filtering> and a texture_2d<f32, non_filterable> at one call site, but then applied to a sampler<filtering> and a texture_2d<f32, filterable> at another call site. It is not possible to trace t back to a specific binding to decide what constraints to apply to s. Each call to twice must be analyzed separately to infer the filterability parameter for s.
• KN: Tried to write this limitation, but didn’t have clear language to use. Spec doesn’t correctly define this right now (!). The thing that says we should look at all texture calls doesn’t actually explain how to do that. Filed a bug for this. So we have to formalize both of these things. So whatever we have in practice right now is what we want to allow here.
• JB: I think what we need is something like the uniformity analysis, where we have an analysis that can produce information that says “if this parameter is uniform, then this other thing is uniform or not (etc)”. So we can capture the function’s detailed behavior there. So I guess we are going to end up building another type-inference algorithm!

[Explicit BGL params] Should texture parameter names match the API spec? #5359

• DS: I think the answer is “no, they don’t need to match”.

Change layout: 'auto' algorithm so it doesn't generate invalid bindGroupLayouts #4952

• JB: Gather that this was found from CTS. Seems like a bug caused by the default pipeline layout algorithm being too naive. So I guess that the work we are doing here provides clarifying context for how to fix this bug. But this could also be fixed in isolation. Does anybody see how a natural fix for this issue could cause problems for the explicit binding layout proposal?
• DS: I think the table David added would help clarify #4952, shows why it is safe to do those conversions. Gregg is proposing basically the same thing.
• DN: I would want to hold off on this fix until we have the bigger picture. This is an API question.
• JB: So you think it’s likely that further discussion on bindless and explicit bindgroup layout parameters will affect #4952?
• DN: I would just like to pump the brakes and not do this so quickly. I can imagine that we may make this fix, but just want to think this through and make sure we’ve thought about the consequences. For example we have had arguments where there is an action-at-a-distance discussion and so want to have a consistent conversation about that.
• JB: Yeah, this doesn’t seem urgent.
• DN: I think this only allows more behaviors in the future, doesn’t change existing things. So it is a safe thing to do at some point.
• JB: The stated goal is “please have the default pipeline layout creation algorithm not produce nonsense”, so you can’t lose.
• DN: This has been around since November of last year. Not super urgent.