Skip to content

WGSL 2025‐03‐11 Minutes

Jump to bottom
Kelsey Gilbert edited this page Apr 1, 2025 · 1 revision

WGSL 2025-03-11 Minutes

🪑 Chair: KG

⌨️🙏 Scribes:

🗺 Location: meet.google.com

⌚ Time: Tuesday **11am-noon **Americas/Los_Angeles (Atlantic-timed)

Specification: https://webgpu.dev/wgsl

Meeting Issues: Marked Issues

Open Issues: Untriaged, M0, M1

Todos doc: WGSL TODOs

Previously: 2025-02-18 WGSL - Agenda / Minutes

Note: These are the minutes taken in real-time. The official minutes can be found on the WebGPU wiki.

If you didn't receive a meet.google.com invitation and plan on participating, please send dneto a Google Apps enabled address and he'll add you.

📋 Attendance

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

  • Apple
    • Dan Glastonbury
    • Mike Wyrzykowski
    • Myles C. Maxfield
  • Cocos
    • Huabin Ling
    • Zeqiang Li
    • Zhenglong Zhou
  • Connecting Matrix
    • Muhammad Abeer
  • Google
    • Alan Baker
    • Antonio Maiorano
    • Ben Clayton
    • Brandon Jones
    • Corentin Wallez
    • dan sinclair
    • David Neto
    • Ekaterina Ignasheva
    • James Price
    • Kai Ninomiya
    • Natalie Chouinard
    • Peter McNeely
    • Rahul Garg
    • Ryan Harrison
    • Stephen White
  • Intel
    • Hao Li
    • Jia A Chen
    • Jiajia Qin
    • Jiawei Shao
    • Narifumi Iwamoto
    • Shaobo Yan
    • Yang Gu
    • Yunchao He
    • Zhaoming Jiang
  • Kings Distributed Systems
    • Daniel Desjardins
    • Hamada Gasmallah
    • Wes Garland
  • Microsoft
    • Damyan Pepper
    • Greg Roth
    • Michael Dougherty
    • Rafael Cintron
    • Tex Riddell
  • Mozilla
    • Ashley Hale
    • Erich Gubler
    • Jim Blandy
    • Kelsey Gilbert
    • Teodor Tanasoaia
  • UC Santa Cruz
    • Reese Levine
    • Tyler Sorensen
  • Unity
    • Brendan Duncan
  • Dominic Cerisano
  • Dzmitry Malyshau
  • Eduardo H.P. Souza
  • Jeremy Sachs
  • Joshua Groves
  • Iwo Plaza
  • Lukasz Pasek
  • Matijs Toonen
  • Mehmet Oguz Derin
  • Michael Shannon
  • Pelle Johnsen
  • Robin Morisset
  • Timo de Kort
  • Tyler Larson
  • Jason Erb

📢 Announcements/Meta

Office Hour

FYIs and Notable Offline Merges

⏳ Timeboxes (until XX:20)

Make template enumerants context-dependent names · Issue #5082

  • (Needs Milestone!)
  • KG: Having a var of read can't use it in var<storage, read> anymore. Agree with reserved WGSL namespace this becomes a non-issue. Personally, feels like we could wait for that.
  • JB: Seems to me like it should be no problem to do this for var specifically, but for template params of types it could leave us with some thorny requirements because of storage texture template arguments. At the moment, when we see a type in a construction expression we are able to resolve the reference of the type name and the template params in the same way. If we tried to make it so that texture format enumerants were not subject to shadowing then we'd have to first resolve the name of the type before the < and then based on which type we found apply different rules for resolving the identifiers which appear as template arguments. That seems subtle. So, for var this is a slam dunk, for type template, seems like it could have unpleasant consequences.
  • DS: Don’t you have that already with like vec args vs texture
  • DN: vec is already not reserved. There is a slippy slope here on what we can make work. We could make this work, but we end up with more and more rules and what rules apply where. There could be a dividing line if you specify the template with a keyword, then we know what it is. The type names because they can be aliased has multi-level lookup. Compromise position of what is keyword and what isn't. We started with keywords, and then removed a lot. Keywords are strongly anchoring. Not in rush to do analysis of what this requires. M2 is what I'd aim for (which is where the wgsl. namespace is as well)
  • JP: Sounds like maybe we could do this for var but not types. Don't like the idea we'd sometimes resolve early and some later. We have enums in both types which goes in var and storage texture. Don't like the inconsistency with resolving those.
  • JB: Disbelieve that changing var rules will cause confusion. Will the rules get more subtle, I believe the way people think when writing programs, having different rules for var args and templated types will not cause confusion. I don't think they look at them as the same thing.
  • KG: If we're satisfied with waiting for namespaces and seeing if this continues to be an issue. Do you think we'd want this even with namespaces?
  • JB: Don't want to suggest folks write var<wgsl.storage> don't want that to be a recommendation. Worried about confusion. Also a worry about shadowing of things which are meaningless to shadow. You can define storage and break var which is very weird. So, we have to make a choice and I think we should just not permit shadowing in places where it is unexpected. For milestone, I think M2 is fine.

"shader-f16" requirements exclude all Qualcomm devices · Issue #5006

  • KG: Because Qualcomm is missing uniform and storage buffer 16bit access. Have storage buffer 16bit access. No f16 load/store directly from uniform. Sounds like consensus to polyfill this and implementation can just not expose this feature on Qualcomm until we polyfil.
  • DN: There is no hardware issue, QC could solve this with a new driver.
  • JB: I wonder if some of the words were swapped. My understand is 16bit stores to storage buffer does have limited support. But, 16bit loads from uniform buffers are widely available.
  • KG: Other way around.
  • DN: All QC devices which support independent 16bit store to storage buffers. Driver compiler does not expose 16bit load from uniform buffers. It's a constant and you could load both 16bits and chop up. Didn't want to do work, so we need to polyfil.
  • JB: So, workaround is to polyfill loads from uniform buffers only. KG posted some code for hte workaround (32bit load and use WGSL function to select vector element) and expanded to an f32 and convert down to f16. Seems like low overhead polyfill so seems good.
  • DN: Also, should not have an out of bounds consideration. Won't have ½ inbounds nad ½ out. If reading bytes 1,2 then fine to read 3,4 due to buffer binding granularity. Similar cases to drivers that allow 16bit types in buffer but not in IO but we do other magic.
  • KG: Consensus is we'll make it a requirement for our spec to retain this requirement and we'll polyfill.

⚖️ Discussions

Sized Binding Arrays: Decide what can be arrayed and the syntax. · Issue #5084

  • (to reach consensus on what to support, and the syntax for uniform/storage buffers)
  • KG: Question, why binding_array and not array.
  • DN: For storagebuffer can store array which is a binding. Now we want array of binding. So ambiguity for storge buffers.
  • KG: Array of bindings or a single binding of a bunch of arrays.
  • JB: Can post nicely composed answer to the issue.
  • KG: Otherwise, everyone is onboard and think name is fine. Seems like a few things we said are TBDs are according to David probably arrayable. Think they are anyway. In practice can we implement or we should make them arrayable?
  • DN: They are all arrayable as far as I know.
  • KG: Resolved. Yes.

Sized Binding Arrays: Uniformity of accesses · Issue #5085

  • (to tentatively agree on uniformity rules)
  • (Needs Milestone!)
  • KG: We have a list of features that we'd need for this that DN provided. DN mentions the last 8 in the list are in VK1.2. The feature bits are available.
  • DN: Feature bits are in structure that is part of vk1.2 Does not mean they are required to be supported. 2022 roadmap says midrange and above must support. As far as I know 1.2 is not common in Android.
  • AB: 1.2 was never released on Android. 1.3 was released but not 1.2
  • DN: Guidance from VK WG provides directionally for ecosystem. If targeting new devices from 2022 onwards, should have these things. Pixel 4 doesnt' have, Pixel 4xl does. That's a 5year old top of the line phone. Could simplify our lives by saying 2022 is fine for VK. So, could just say allow all of this stuff and makes our implementations simpler. Possibly cuts off trailing edge devices and maybe that's ok due to forward looking.
  • KG: Idea for this is it would be a feature.
  • DN; exactly, not trying to capture whole universe. That's the strawperson.
  • JP: You mean language feature or extension
  • KG: extension …
  • JP: Being prototyped as language feature, assuming ti would be available everywhere.
  • KG: Do we think we can do it everywhere?
  • DN: No
  • KG: then can't be language feature. If it can be implemented everywhere then language feature, if not then needs to be checked
  • DN: Or need to make the dynamism … (something) … of the hardware feature.
  • KG: Was referring to API feature which are queryable. Unless everyone is implementing and we're adding to core webgpu then this needs to be a webgpu feature anyway. It interacts with binding code, the bind groups are different. So, frees us a little. Forces it to be a webgpu feature (an optional feature) and then the question is if we want to split that into 3 things, static indexing, dynamic indexing and non-uniform indexing.
  • DN: Would suck to spit 3 ways.
  • KG: Hopefully 2 of the 3 can go together but those are the 3 conceptual things. That's the investigation we need I think. These are feature bits, so we don't really have good data (probably) on prevalence.
  • DN: Would have to look
  • KG: Should be collecting this data.
  • DN: Don't feel ready to make a call, but directionally, don't want too much fine slicing. If we cut, between 2 partitions.
  • KG: Think the goal is 2 but there are 3 cases. Static indexing would be language-feature-able. That's just non-indexing with fancy numbers. Seems we could spec the simplest thing and then do investigation to see how far that would go.

WorkgroupUniformLoad can return fixed-footprint arrays instead of creation-fixed-footprint arrays · Issue #5093 · gpuweb/gpuweb · GitHub

  • DN: You can have an array in workgroup storage where the array is sized by an override. The workgrouUniformLoad can return the whole array which goes against intuition you can fit in virtual register. This is about, no you can't do that, the only way to use the value is to post-index it, so move index into pointer expression.
  • JB: Agree with what DN said in bug.
  • KG: Sounds like agreement then.
  • MW: <thumbs up>
  • KG: M1.

📆 Next Meeting Agenda Requests

  • Next meeting?: Tuesday April 01, 2025, 11a-noon (America/Los_Angeles)
  • But email Kelsey or the list if you want to meet sooner!

Clone this wiki locally