-
Notifications
You must be signed in to change notification settings - Fork 304
WGSL 2023 10 10 Minutes
πͺ Chair: AB
β¨οΈπ Scribes: DN
πΊ Location: meet.google.com
β Time: Tuesday **11am-noon **Americas/Los_Angeles (Atlantic-timed)
Specification: https://webgpu.dev/wgsl
Meeting Issues: Marked Issues
Open Issues: Outstanding V1 Issues+PRs, Untriaged WGSL issues
**Todos doc: **WGSL TODOs
Previous: 2023-08-08 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.
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
- Kai Ninomiya
- James Price
- Rahul Garg
- Ryan Harrison
- 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
- 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
- Aura Munoz
- Lukasz Pasek
- Matijs Toonen
- Mehmet Oguz Derin
- Michael Shannon
- Pelle Johnsen
- Robin Morisset
- Timo de Kort
- Tyler Larson
- Jason Erb
- Wednesday 10am-10:50am
- https://meet.google.com/xrp-hpck-vmy
- Everyone welcome
- Mass calendar invite will have been sent out
- If you still need an invite, add your email here:
- [email protected] (example)
- If you still need an invite, add your email here:
- Are we ready to land changes for milestone 1?
- JB: Mozilla still implementing the βv1β. Donβt hold back the spec. Snapshot would be nice. Fine to add new features.
- TT: Adding extensions, for things to core.
- AB: We have βlanguageβ extensions that can appear anywhere, and βenableβ extensions which depend on HW. There are PRs up for the first kind.
- https://github.com/gpuweb/gpuweb/pull/4312 fewer restrictions on pointer parameters. Can discuss later.
- TT: Q is mainly if there is optional functionality weβre talking about.
- AB: What WGSL describes as βlanguage featuresβ, all implementations are expected to eventually support them.
- Do we wish to snapshot the βv1β version of either/both specs?
- Any to push?
- Any issues that should be pulled in? (untriaged issues)
- AM: Want the equivalent of gl_PrimitiveID. Currently in M3. Whatβs the process for pulling in? https://github.com/gpuweb/gpuweb/issues/1786
- AB: Post comment saying you want this. We need that feedback. Suggest a first round of your own triage
- AB: https://github.com/gpuweb/gpuweb/issues/1791 suggest pushing this out since we have the opt-out.
- AB: Call to action. Homework: Please make your own opinion known.
- AB: Previously decided against this, happy to leave as is
- JB: Mozilla favours status quo.
- Agree to leave open, but not revisit soon.
AbstractInt conversion ranking forces unfortunate compromise
- DN: no desire to have values affect type checking
- JB: Example shows it.
return bitcast<u32>(0xffffffff);
- Fails because that literal doesnβt fit into i32.
- JB: Still would like to see a change to bitcast. Think Bitcast should have an overload for AbstractInt to make it work if it the value fits in the target type.
- AB: Iβm a bit on the fence on this. Maybe wordsmithing can help. AbstractInt is 64 bits now but could be expanded. Do you feel -1 should work the same way? Once you have all the leading 1s, is it in range or not is a question.
- JB: 2**32 - 1 is a representable as u32. Itβs unfortunate we have all these first class citizen values. Iβd be happy to say bitcast to a type should be able to accept all the values targeting that type.
- AB: Is it bitcast the only one that is problematic?
- AB: The constructor with u32(-1) feels in the same vein as youβre asking for.
- JB: -1 isnβt in range for u32. Thatβs a step beyond what I might like.
- AB: We made a special case constructor for abstract int.
- DN: could probably get behind this because AbstractInt was not meant to have a bit representation, but we says it needs at least 64 bits. Would you extend to f32?
- JB: probably not. Fewer variations for integers.
- DN: Iβm ok with adding bitcast(AbstractInt), must be value-preserving.
- Consider resolved; letβs look at the PR.
#4312 Remove restrictions on user-defined pointer parameters
- Review WGSL language feature name
unrestricted_pointer_parameters
- AB: David merged this prematurely. Two questions. 1. Review language feature name, 2. Intentionally didnβt want to pollute the spec with a mass of conditionals and interactions. In this case itβs a deletion of a bunch of text (which is now lost).
- JB: As long as itβs sufficiently clear whatβs disabled, itβs ok ot generally describe the spec as all features are on.
- DN: In this case itβs an entire deletion of sets of conditions.
- TT: Descriptions is too vague in this case.
- AB: This case we can reword. Pull the restrictions into the description of the feature.
- JB: That sounds better.
- BC: The name is quite wordy. The language uses βptrβ, use it there?
- Leave the name as is.
- AB: Iβll revert this, make changes,** tag the spec, and Iβll draft the new changes.**
- PR: #2378
- AB: Google wants to ship this.
- AB: After internal discussion, we asked to add the accumulator back since it will be polyfilled if support is missing; map more directly to HLSL. Can supply 0 to get the non-accumulating form.
- SJ: Then we need to consider the overflow issue on the accumulator
- AB: Language extension name is a suggestion.
- AB: Assume overflow is like any other integer add (on concrete type) which is wrapping behaviour. In SPIR-V the accum is separate instruction, so assume wrap. Need to check what HLSL says/ spir-v says dot product overflow yields indeterminate value.
- JB: In general use this applies to u32 read from a buffer. If you did the pack/unpack yourself you probably lost the throughput.
- AB: Pack/unpack is for assembling data, and supplying a constant. Yes, generally think the data comes as u32 from a buffer.
- JB: No strong opinion on accum/non-accum.
- AB: Chrome/Dawn has experimental implementation of non-accumulating.
- JB: Fits directly onto a machine instruction. Is your peephole optimization not effective?
- AB: Thatβs a reasonable expectation. SPIR-V arrived at a different answer than HLSL. SPIR-V thought addition was only worth combining for the saturation case.
- JB: ML folks seem to have moved to 4bit values, and so maybe donβt worry too much about this optimizing perfectly. Letβs ship something here ASAP.
- AB: If we prefer to leave it off, then weβre ok with that.
- JB: easier to document the feature without accumulation.
- Consensus to keep it as the non-accumulating form.
- AB: Google would also like to ship this
- AB: have an experimental implementation with subset of formats available behind flags in chrome
- AB: partner request
- β-------
- AB: Thanks Teo for all the work driving this. My understanding is we can make this core language feature. The old apple devices are aged out.
- On the API side they have to validate βoriginal tier1β in core, and βoriginal tier 2 + 3β as a separate GPUFeature. But WGSL just adds the enums without distinguishing.
- TT: yes, think so.
- JB: Barrier is for visibility between invocations in a workgroup.
- AB: Self-fence is required, and will be injected by our backends for Metal.
- Consensus. Get a βlanguageβ feature that adds readable storage textures, and read-write storage textures. API side finalizing elsewhere.
Teo: What about adding write-only storage buffers? Thatβs missing from the matrix.
AB: I remember discussing this. We didnβt expect there to be a performance benefit, so it didnβt seem necessary to expose it.
Teo: Can see that storage buffer is different enough from storage textures.
- No discussion
- Next meeting?: (Atlantic-timed) Tuesday October 17, 2023, **11am-noon **Americas/Los_Angeles