Skip to content

WGSL 2025‐02‐18 Minutes

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

WGSL 2025-02-18 Minutes

🪑 Chair: KG

⌨️🙏 Scribes: ds

🗺 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-01-28 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)

Add limited support for 64 bit atomics · Issue #5071

  • JB: As far as community is concerned, WGPU has an implementation of this which Bevy wanted. Crucial for nanite. Shipped in WGPU v24. Pretty desirable. People get a lot of milage out of this, allows new rendering pipeline. Nainte/deferred rendering. Think, assuming we can do this without too much effort, mostly just new functions we add to access textures atomically. Think it has an audience.
  • AB: What did WGPU implement? Range of possibilities. We don't have image atomics now. Would be good to know what has been implemented.
  • JB: Several things that are non-overlapping.
    • 6 different atomic ops, like xor on 32-bit texture formats (storage textures)
    • atomic min/max only on 64-bit texel values. have storage image with texelformat r64uint and then can do atomic min/max only
    • Have operations which return 64bit integers. Don't think anyone wants this. Seems mostly doing is breaking into 2 32bit values and using that way. Compromise of vec2u maybe better dev experience.
  • JB: One capability which enables 32bit and a wide range of ops and a separate capability to enable 64-bit atomics with min/max. Possibly also another restriction of if it returns a value. Some of these on mac are side effects but don't produce a value
  • AB: No compare/swap, just load/store for min/max? Image atomics is a separate feature this would be built on
  • JB: textureAtomicMin, textureAtomicMax, Add, And, Or, Xor. May or may not return a value. Can do min/max on 64-bit integers in storage address space when return value is not used. Only 64bit atomic functionality in metal 3.1.
  • JB: We need to research what is portable.
  • MW: We are proposing this as optional extension?
  • JB: Yes.
  • AB: Would be good to clarify if we separately want image atomics and if they want them in storage buffers and workgroup
  • KG: Think they linked 2 different merged prs for bevy. One I believe used storage and the other image. One other thing proposed, the 2 was. This need for 64-bit things, but really 2 32-bit things, if we expect in the future to add true 64-bit fields, because we will probably have 64-bit in the future. would think it's fine for any builtins to be a little warty. It's fine if they aren't inline with exactly what we do in the future because that will probably be real 64-bit. Dont' have to make one look like the other. Fine to have these now and in the future accept as technical debt. As long as the usecase is narrow. Texture atomic max on 64-bit value loaded as "whatever" it's fine if that's a weird name. Feels a lot like we're reaching out in front of the main language style but that it's worth it in this case, and easier ot accept that's true as long as it doesn't cause too much future pain.
  • JB: In bevy case it's a narrow hack. So can provide exact thing they need.
  • KG: textureNaniteAtomic (not really). Looks like we need fact finding for shape of API and then into PR welcome land. Adding both for image atomics and storage buffers. Even though these might feel like they could be different features because they attach to different api parts think it's worth considering if there is no difference in support matrix they should be the same feature. Do you have 64-bit atomic load stuff.
  • AB: We don't currently have the base atomics stuff for textures. Would we want that as base feature first. Is it language feature (don't think it can be as it's not available everywhere). So sounds like 2 enables, one for image atomics and one for 64-bit atomics.
  • JB: I think that's what naga has
  • DN: Image atomics are interesting. For all other atomics have to pass ptr into storage and you'd need to say this is the address of a texel, no way of saying that. SPIR_V has imageTexelPtr. Having image atomics feature helps resolve that design question of how to resolve in language so like separating.
  • JB: Metal and HLSL just both had functions on textures. Introduced a separate vocabulary of atomic ops
  • AB: Easy way is a bunch of overloads like textureLoad/Store where you give it coordinates over the array.
  • DN: Probably the right thing. Bit I'm exploring is analysis tool that wants to see all the places I'm talking about modifiable memory. See & and know I'm doing something. Maybe that's too exotic use case to worry about. Usability with a builtin is easier. More names and things in analysis case but maybe the right balance.
  • (KG: See also:)
  • PM: Have a work in progress proposal which looks at Metal support and things. It's not complete but could try to finish polishing it and push it as draft proposal and take into account comments here and then can come back with it. Have covered the metal support of max, no returns, no load/store beyond max/min.
  • KG: See that as them doing the atomic op nanite. Same kind of thing where they picked the one piece and figured that was what was needed
  • PM: I have enable atomic_64_min_max and atomic_64_ops
  • KG: Can see links above for different enables for 64-bit all opts and min/max.
  • PM: To support usecase, cant' they use a storage buffer, do they need/have to use an image? Is it performance? Can't just read/write memory?
  • JB: Don't know, good question.
  • KG: Think you probably can ….
  • PM: Can read/write memory and read back in another pass. Maybe not tiled or swizzled
  • KG: Not having tiled sucks, so important to have tiled. Probably the compelling component to it. If you have a WIP proposal sounds like that's what we want. Some fact finding to do, but proposals are cool. Since we have cases in WGPU of folks using, one path would be to show what we did there, here are the web bindings. Anything like that. Game of let's propose and make sure it fits use case. More research and then we come back to this.
  • DN: Milestone?
  • KG: 2 ? We're actively developing 2 now.
  • DN: SGTM.
  • Resolved: Proposal PRs welcome!

[WESL] Host-visible names that shadow predeclared names · Issue #5070

  • JB: Trying to build an import system to stitch together files into single file you acn ship to browser. In general, any time you have a tool that substitutes one piece of code into another texturally (macro sub, etc) you have to worry about binding capture. Have to amke sure the bindings you inject still refer to the things they were intending to refer to and aren’t being captured by local definitions in the code you're substituting into . Because WGSL has no namespace concept there is no way for the injected code to reliably refer to the global bindings for things. Can't put std:: in front of something or a leading :: or whatever. Because we don't have that machinery, it's impossible to do the substitution cleanly. In particular, because entry points and overrides need specific names can't just rename everything in the surrounding code. Sometimes we have to leave the names in the surrounding code exactly as it is. Then new injected code cant' refer to the bindings it wants to refer too. Priority wise, seems like they can just forbid naming things after builtins. Pain to maintain table, inconsistent to have rule, but don't think it needs to be a priority just because of this usecase.
  • DN: Seems to be a usecase that motivates 4308 which is slotted for M2. 4308 is WGSL namespace which is the cut down full namespace issue.
  • KG: Since that's M2, can make this M2
  • DS: Just dupe?
  • KG: Wish we could conditionally dupe something to make sure it's fixed when done. Only reason to not fully close is if we decide to not do 4308 then would lose usecase. Will mark and leave for later.

Add builtin swap function · Issue #5060

  • KG: Very clear it's a QoL thing. Seems to be all it is. Instinct is to toss into M3+ unless someone wanted it to be done sooner.
  • DS: Is it worth it?
  • KG: Ergonomically it would be cool. Nice to have until folks can make themselves. Even if can, nice to have a swap operator. Minor thing. Will need someone to stand up and say they want it but not urgent until then.

Proposal: "auto" layout algorithm should be able to generate any layout · Issue #4956

  • KG: Last comment from Kai, last thing we need is a way for a sampler to say non-filtering. Would allow auto-layout generated with the needed things. Theoretically possible to have the us determine by use but if we did that it would be spooky action at a distance as you change how you access the texture and bindings would fail to attach. This moves the spooky action to less far away conceptually. It's written into the binding if you expect it to be filterable or not. Possible we're just waiting for a proposal
  • MW: Was wondering if we considered how this may interact with the bindless proposal which is on-going. If that's going to impact how useful this potentially is.
  • KG: Good question i don't know
  • DN: In general, how does bindless interact with auto-layout at all? (I don't know)
  • MW: Yo don't know your bindings at shader compilation time but you may not know your layout until the encoding time.
  • JB: There was discussion in previous meetings about if these annotations (attributes) really belonged in the sampler type and i didn't see in the minutes a clear decision aboutthat. Seemed like DN wanted to think about it.
  • DN: If you encode this into the type you have this additional rigidity where you can't pass the samplers because we dont' have templated parameter types which seems annoying and a lot of hoops for no reason. So we'd be modifying a bunch of shader code for things which aren't a shader concern. It's a n API concern. Better to have as an attribute on the var and not the type.
  • JB: Sounds great
  • DN: If we had union types but we don't and won't any time soon
  • JB: Or generics or something.
  • KG: Sounds like waiting on proposal. Kai had a tiny sketch of a proposal and sounds like if made into PR we'd consider it.

⚖️ Discussions

Can float -> int conversions be relaxed at upper/lower bounds? · Issue #5043

  • MW: Trying to get more CTS tests passing and fp to int conversion where value does not map to u32 value to due impreciseness of floats. To not hit undefined behavior sanitization (UBsan) only found triple branch method. Prior discussion in #3908 causes a conversion from out of range f32 to u32 which is technically UB and UBsan detects it. Proposal is to have some type of either relaxing of spec or potentially conversion function so if the author knows value is in range don't have to pay penalty of 2 conditional operations which does not appear to get optimized by the compiler.
  • KG: Found it compelling that it sounds like there is no other spec which does as good as a job as we proposed. Us wanting to do better was contingent on it being easy to do better. Probably worth revisiting.
  • DN: Talked about doing cheap polyfills.
  • KG: Do we want to relax and figure out what to relax too
  • JB: Thumbs up
  • DN: Have a bit of grief is the feeling I have. If I was a dev I'd want it fast by default, probably. Moved emotionally by JBs argument that it's UB everywhere else, what do we care. Why are you relying on it.
  • MW: Reason it's important to not gen UB, because generating UB with metal compiler doesn't only impact float to int conversion but subsequent instructions.
  • DN: Yes. Totally agree with that
  • JB: Mozilla is on board with that.
  • KG: With grief …
  • JB: Can provide a builtin which does the right thing if folks want it/need it.
  • DN: Know you can give them all the tools but they could also write it themselves. They could write that code sequence and a little peeved by things like opencl which has cos and native_cos which is the fast thing. It's a little warty to do that. My preference is if we change to just change and note it in the spec (update the examples) to say you'll get this, not the max value. Like min int / -1 is a bad value for reasons. I have grief. Someone will eventually update the implementation on our end and update the CTS.
  • PM: My only thing was that because a lot of times you're doing f32 -> i32 you're doing int for accessing and a lot of times the accesses are bound and we're doing more checking after that. So some of the checks if the compiler is smart enough would remove the check. Not sure how strong the argument for perf is.
  • DN: Before meeting tried tiny program running through metal and Tint and early on the conversion gets wrapped into an AIR (AppleIR) intrinsic and then goes through the code sequence tint makes and the min we do is also an air intrinsic and does not get folded away. Will share offline. In the 5minutes I looked did not fold away.
  • PM: If its' constant array access it should fold away
  • DN: I tried array size and it didn't fold away. Could be addressed by future version of the tools.
  • Resolved: Relax requirement, please make a PR!

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

  • Still waiting on feedback.

📆 Next Meeting Agenda Requests

  • Next meeting: Tuesday March 11, 2025, 11a-noon (America/Los_Angeles)
    • (Can we talk about:)
    • Sized Binding Arrays: Decide what can be arrayed and the syntax. #5084 (to reach consensus on what to support, and the syntax for uniform/storage buffers)
    • Sized Binding Arrays: Uniformity of accesses #5085 (to tentatively agree on uniformity rules)
    • WorkgroupUniformLoad can return fixed-footprint arrays instead of creation-fixed-footprint arrays #5093
  • But email Kelsey or the list if you want to meet sooner!
  • Notable merges:

Clone this wiki locally