Skip to content

GPU Web 2025‐10‐14 WGSL

Jump to bottom
Jim Blandy edited this page Jan 10, 2026 · 2 revisions

Attendance

WIP, the list of all the people invited to the meeting. In bold, the people that have been seen in the meeting:

  • Apple
    • Mike Wyrzykowski
  • Google
    • Alan Baker
    • David Neto
    • James Price
    • Peter McNeeley
  • Microsoft
    • Rafael Cintron
  • Mozilla
    • Jim Blandy
  • WESL
    • Lee Mighdoll
  • Connor Fitzgerald

Add proposal for explicit binding layout parameters. #5353, #5354

  • DN: Companion to bindless, and to a previous discussion about auto-binding layout. Has to make default choices about texture that are filterable vs samplers that are filtering. No way for shader to express that it is not in a given corner of the space. This proposal puts that information into the shaders by adding another field to the texture/sampler type declarations. Went through a couple of discussion (e.g. attributes vs not), landed on something embedded in the type system. Ready for other people to take a look, but not a firm design statement from Google yet. For bindless, need to avoid UB when loading a texture/sampler from an array, needing to validate that texture/sampler modes match.
  • JB: With this additional information in the types, enables more validation on the WGSL side?
  • DN: Yes, given the information we are given about these samplers/textures, we can do that in some of these cases.
  • JB: That’s point 2 on line 57.
  • JB: Now we have to think about passing params into functions. Line 111.
  • DN: That design was up to debate, about convertability.
  • AB: Something like if a sampler was non-filtering, then you could pass either kind of sampler into it. Stuff like that.
  • CF: What if you passed nothing in that param.
  • AB: You have to trace through the shader to look at all pairs of sampled texture calls, and then deduce need /demand for filtering. For now, you default toward filtering.
  • LM: Isn’t that fragile?
  • AB: That’s part of the motivation. Author tells us.
  • CF: That’s part of my worry. Right now it doesn’t matter; you can write code that’s generic over any.
  • AB: It does matter. It just changes where it’s checked. It still matters today, if you use it in a way that’s only filterable, then you’re stuck on the API side. The way defaulting works today limits what the user can do, and it leans one way.
  • CF: The user could still write texture_2d with no additions.
  • AB: Yes.
  • LM: If we have a linter, we recommend people not do that any more.
  • CF: I was mainly thinking about transpilation.
  • AB: That came up in internal discussions. That’s one of the differences between WebGPU and other platforms; the additional validation makes it tricky. Coming from SPIR-V or others like this you need to pass in side-band information to carry intent.
  • LM: Sounds like there’s an implicit; if generics were a real thing at some point ,there’s an implmicit hierarchy, that filterable and non-filuterable relate to each other.
  • JB: We have automatic conversions in the spec right now. Spec doesn’t talk about subtyping ,but it does talk about conversions,. I wonder if it slots into conversions area.
  • AB: Yes, agree.
  • JB: Consensus to land this as proposal.
  • AB: Issue #5353 is the umbrella issue to track sub-discussions.

Limit the value passed into @align? #5150

  • DN: Filed by Dan. Fuzzers were injecting very large values for these attributes. Our GLSL backend then pads by emitting a large number of u32 fields, which causes issues. Raised question about whether we should reject this. Looked into using arrays instead, but then zero initializer for these structures has the similar problem. Also a question about divisibility of the address, and we cannot guarantee more than 256 anyway, so perhaps we should limit to 256 anyway, but that would be a backwards incompatibility.
  • MW: We support limiting it to 256 or lower.
  • JB: Mozilla does too. If the concern is that we are generating ugly shaders, there are things that the user can just type, they can also do this. So if we are going to plug this existing loop hole, we should also look at other similar lines of attack. We were looking through the spec to look for other places that limit the size of a constructible type. The closest thing is a limit on the size of private variables, and the maximum number of elements of a value constructor of an array type. Should file that as a separate issue to this.
  • DN: We weren’t 100% sold on limiting the value to 256. Shifts burden back to the shader author when they have a legitimate desire to add padding without adding dummy fields. Not sure we should change the spec in that respect. Maybe have something noting that the only guarantee we get from GPU buffers on the API side is 256 byte aligned. The fact that you can cause this downstream shader blowup is probably hard to fix. Not sold on changing things.
  • JB: So first choice is to continue with ridiculous GLSL?
  • DN: Yes. People will be able to write haywire-inducing things anyway. So don’t put in a stumbling block to people.
  • JB: So if people happen to know they have this stuff where there is a large gap, it’s nice to be able to use @align(large_number) and they get the layout to where they want.
  • CF: Could the backends initialize the array in a loop?
  • DN: Could do, haven’t done it yet.
  • MW: Wondering about the legitimate use case. Can’t they use @size() for this?
  • JP: Yes, but @size has the same problem as @align here.
  • JB: Yah, came up in other discussion.
  • CF: If I can put a large number in one of them, then we need to eliminate them all, rather than just one. Agree that it is unexpected that putting a large number in one would cause code size to blow up.
  • DN: When I made the change, only the same examples needed the array initializer, so only a small fraction of users would hit the case where this blows up.
  • JB: Now feeling that the consequences of this problem are not serious. Sure we have ugly output, but people have ugly input too. Not a UB issue. So I'm wondering how urgent this is to fix at all.
  • DN: A reasonable user agent could limit to 16k and then just drop the user on the floor, without us baking this into the spec.
  • MW: To Jim’s comment, do believe that with MSL compiler we have observed some issues with compilation times when you pass gigabytes to the array constructor.
  • JB: Naga already imposes a limit on the size of things.
  • JB: What further action is needed? Resolve as wontfix?
  • CF: Seems reasonable.
  • CONSENSUS: No spec change

Language feature for relaxing uniform address space layout #5347

  • AB: Talked about making every address space have the same constraints. Right now uniform has 16-byte alignment requirements on arrays and structures. This would remove them. All platforms can do this already, or with a polyfill behind the scenes. Did this a bit different based on feedback about pointer parameters. Here I left the non-language-feature version in here too.
  • JB: The reason this can be a language feature is that anybody can lower operations on these types to just word operations, and treat the uniform address space as an array of vec4u.
  • AB: Yes.
  • JB: Seems fine to us. I did want to know, if we offer this as a language extension, are we allowing people to do something that was slow? Imagine some GPUs have a constant store that gets broadcast to all units, maybe addressed in 16 bytes instead of word addressed. So by doing this we maybe change 16-byte accesses into word addressing. So are we inviting people to do something that is slow instead of warning them about it?
  • AB: Personal opinion is no. Metal and D3D have this on by default. Before we turned it on for Vulkan, most devices supported it. We relied on it in clspv 5+ years ago. Feel it’s keeping up with the times.
  • JB: View it as the old rule covering for the oldest parts in people’s product pipelines.
  • CF: We already have performance cliffs like this. Reading from an aligned vec4 is faster than reading individual words. Not worried about it. Makes the APIs less confusing. Have had people screaming at me about scalar layout.
  • JB: This is a draft PR. Sounds like general positive feelings about it.
  • AB: I made it a draft to avoid sending pressure signals. It’s ready for review. Taking feedback on wording, and name.
  • JB: Let’s give this one more week for wordsmithing.
  • DN: Implementation is WIP. Mostly happy with it. Have found two driver bugs that we will note as errata.
  • JP: Worth noting this gives you the ability to launch f16 on Qualcomm devices. The same transform gives you the polyfill you need.

[subgroup-id] Specify range and density of the IDs #5344

  • DN: Noted that the subgroup_id proposal does not specify what numbers you get. Assume that it should start at 0 and go up to (num_subgroups - 1). In another issue Alan notes that we should tell developers how many subgroups they get (e.g. add a num_subgroups builtin).
  • AB: Use case is to allocate dense space in memory. We should provide a builtin for num_subgroups.
  • JB: Don’t we want to be able to use the num_subgroups value as the size of an array? If indexing an array with the subgroup index, so want size to be based on the number of subgroups?
  • AB: Best you can do is with an override. You can’t tell at shader creation time. You can know the min and max but not the exact size of the subgroup. On some platforms you can query the number after compilation.
  • JB: So you have to take the adapter info and supply that at pipeline creation time?
  • AB: No because only workgroup arrays can be sized by an override. Could template in typescript though.
  • LM: Floating idea of @param const thing as a super-override. If information is available at runtime, we could query it and put it in?
  • JB/AB: Yes.
  • CF: Wouldn’t get actual value though, just get upper-bound on the potential value. The range varies between 8-32, and on Qualcomm it’s between 64-128. Could get any power-of-two in there.
  • JB: When people are using subgroup_id like this, they big-size the arrays and live with it.
  • AB: Depends on platform and how specific they want to get. HLSL has an option to require a specific wave size. SM6.8. As Connor noted it’s the subgroupsize control extension.
  • LM: Library could run a test program, measure the size, and then compile the shaders?
  • AB: No, because if you compile a different program then it may change the size.
  • CF: For example, I deal with FSR, which has one variant for any wave size, and one variant for 64, because it’ knows AMD can always do 64. Special cases it.
  • AB: There’s not a great solution. It would require additional features from platforms, that don’t exist portably. Metal has a way to query the size you got, from a pipeline, and not control the size in advance.
  • JB: Hoped WebGPU would have coarser grained features, to aid developers. Vulkan is the opposite end, assume it talks to engine developers that are satisfied with very fine grain. Wonder if subgroup-id should be ganged with other features that allow it to be better behaved. E.g. to allow array sizing from pipeline creation time.
  • AB: In Vulkan the feature that makes it convenient is that it’s not available everywhere. The trouble with making arrays more flexibly sized is it defers compilation to pipeline creation time. But we want to avoid that.
  • CF: Are there platforms that generate backend lower level shader code at shader creation time.
  • AB: Yes, safari/metal does wherever it is able to.
  • DN: Yes, in the Stadia era we got a long way to generating backend machine code at shader-creation time. It’s a nice place to be.
  • JB: Mozilla in favour… (?)
  • AB: So adds the feature for subgroup_id and num_subgroups.
  • RESOLVED: PR NEEDED

[subgroup-id] is there an acceptable polyfill on D3D? #5367

  • PM: Did an experiment to investigate the relationship between the invocation ID and the hypothetical subgroup ID. Found a linear relationship where X gets incremented then rolls over, then Y, then Z etc… on everything except some specific Intel devices. Jiawei from Intel confirmed this. When there is a difference, under certain circumstances it will increment the Y first 4 times. So there appears to be only two different ways that the thread IDs are mapped to subgroup ID. No ragged subgroups found yet. So the last subgroup is the only subgroup that has non-active invocations.
  • CF: Have you tested Qualcomm?
  • PM: Should be a Pixel 4 in our test (older device/hardware/driver).
  • CF: Not running D3D.
  • PM: Right, D3D+QC is not tested. Could try and test that.
  • JB: So this means that is promising for being able to synthesize the subgroup_id in a way that would be consistent with what the native thing would do, so positive for enabling as a language feature instead of an enable.
  • AB: You have to ask, how much are we trusting to a test. It’s a lot to put faith that it won’t change in the future. Does it change if you switch the access pattern to iterating on z first. I can see a driver be clever to rearrange orders to make memory access better. Sure linear is most common.
  • CF: One advantage of this is that when we get SM?? (that gets the subgroup_id), we won’t have to build out that database going forward. Also, I know Intel is weird in vertex shaders, but who knows what happens when Intel go into a different wave mode. 8 vs 16 vs 32 may yield different results. Little worried that this will break in horrible ways.
  • RC: +1 what Alan said about running tests. Even in GitHub issue, see what Intel said is that Alder Lake is only hardware that breaks. Intel may not care, but there are a lot of people that have those machines. Asked Jesse and ChrisB: Jesse said he’s OK with the polyfill (did it for VKon12). ChrisB said is that if somebody assumes layout, things will likely break.
  • JB: What we are concerned about is how much trouble we are going to cause people if we say that this is a language feature that we make available to everybody, and that’s 95% of the time no problem. Allows the rest of us to use this with no issue, and as we move to the new shader model the problem goes away. So we don’t need it to be perfect all the time, need it to be good enough to fade out over time and rough patches go away as people upgrade their drivers. So it depends on how bad this will be in practice.
  • CF: Note that Shader Model versions are tied to the OS, not tied to the driver.

Clone this wiki locally