-
Notifications
You must be signed in to change notification settings - Fork 371
WGSL 2025‐01‐28 Minutes
Kelsey Gilbert edited this page Jan 29, 2025
·
1 revision
🪑 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: 2024-12-10 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
- James Price
- Kai Ninomiya
- Natalie Chouinard
- Rahul Garg
- Ryan Harrison
- Stephen White
- Peter McNeely
- 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
- 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:
- kelsey.gilbert@mozilla.com (example)
- If you still need an invite, add your email here:
- Merged
- CR achieved
- Have a first snapshot, every merged PR moves back to draft stage.
- See publication history here: https://www.w3.org/standards/history/WGSL/ shows the status of each iteration
- JB: Rules say can pass whatever kind of pointer you want. If you notice the definition of the unrestricted pointer params it explains that unless the extension is available can only pass restricted kinds of pointers. Makes spec unclear as you have to do a computed come from to figure out what the spec was say. Function call section doesn’t say anything but random paragraph says rule is different. This is a deliberate spec choice as we didn’t want conditional language through the spec, makes it unreadable. Especially for widely deployed extensions. Firefox does not implement, Safari doesn’t state status or plans. I found unclear, community member also commented and as an end user it's unclear. If this was a feature where it was changing all over the spec with conditionals then would say lets just doc in on the description of the language extension. Because documenting this clearly does little change, would like us to tell people what the rules are in the place explaining the rules. Understand what Alan is saying, but in this case think it should be explained.
- KG: Willing to write a PR?
- JB: Yes.
- KG: Expect a PR showing how constrained the change is would make it easier to merge
- DN: Understand the concern and it's a sliding scale of how much change is needed. For example, if f16 was a language feature that would be everywhere. So, finding balance. Write a PR and will review.
- JB: To write a PR if he wants to push forward.
- DN: Goal is to make spec precise and then clear. Clear is close second. There are redundancies. Having worked with specs, any redundancy can be a problem in the long term.
- KG: In general, if we find something unclear, propose a clarity and we'll try to keep a running balance.
- Resolved: PRs will be entertained
- KG: Seems like this maybe a tint bug. Want to make sure we're specifying correctly. Is the spec clear.
- JP: I believe so. Language is about 2 idents having same end of scope. I believe initialize has same end scope as body. That's pretty clear.
- JB: And thus they do conflict.
- JP: Yes
- JB: That's my understanding as well.
- JP: That's what the bug author expected as well, surprise was that Tint accepted it.
- KG: Don't feel it's necessarily clear the spec forbids this. But maybe it's something to introduce clarity. I think using the two declarations must not have same end of scope and combining with us saying where end of scope is makes it different scope. I think it would help to say a declaration within a for loop initializer counts as the body scope. Saying it's syntactic sugar doesn't make it clear that it's forbidden because a naive desugaring would cause it to break. Actually, naive desugar allows?
- JB: Yes, it does. My hope is this isn't spec'd by desugar, and is just spelled out. If it is by desugar then it's incorrect.
- DN: For statement section describes 3 parts of for loop and first bullet point says init element has scope extending to end of loop body
- KG: My reading would cause me to file the same issue as this person filed. Not used to where scope ends being an exclusion principle.
- DN: Scope is not a first order definition in the spec. We just say the extent of the visibility of a declaration is blah. We did approach it a bit weirdly but it is precise. But if you think it can be improved would entertain suggestions
- JB: Groused about rule where if a local var at the top of a function is allowed to have the same name as a function arg. Think that should be allowed, not bringing it up here on this issue because I feel like if we wanted to change it we need to have a discussion to relax the rule. This issue isn't about that.
- Resolved: PRs will be entertained
- KG: Requesting a thing we don't want to do but my worry is that it wasn't clear to the person that these are different things and maybe it would be useful to have clearer categories for these things. We do have some idea of different categories for these.
- DN: That category is sampled type. There is a definition for that "for sampled textures are parametered with sampled type and must be i32,u32,f32". It's in multisampled texture types and sampled texture types.
- KG: Then just editorial, maybe nicer if it's clearer difference between sampled type and type
- DN: Can add examples to spec "using this declaration in shader is usable with this and this and that format"
- KG: And the non-normative of why we did it this way. Otherwise more folks will see this and wonder why we didn't do the other thing.
- DN: Short answer, it's a lot more flexible.
- KG: Falls in pile of "spec has everything you need to know but could be more clear"
- Resolved: PRs will be entertained
- JB: Good discussion on the prior issues linked. Issue is that it's tricky to get fp -> int conversions to saturate in the most natural way. Ideally make closest int closest to float. Turns out to get that you can't clamp because the clamp either requires the value be a float or be int. In either case you end up with mismatch where one can't exactly represent the other. Not simply that int values can't represent all floats, it's that all floats also don't exactly represent all integers. Spacing of int values at top of float range is like 64k. Were going to spec a properly saturating conversion. Focused on double select thing. What Mike is proposing is that we actually not require a properly saturated convert to int. That we allow out of range float values to return a int value near but not at end of int range. The argument goes, these conversions, from out of range float -> int, are bugs in all other shading languages. Errors/undefined behaviour. Float out of range to int is ub. Shouldn't be doing this in good code. It's also very common for folks to do this where they know they are in range. Decision in spec penalizes the common case in favour of folks writing bad code. Argument in bug is just do clamp and then convert to int. Gives not exactly properly saturated but only matters if they do something bad. Clamp and convert would be faster for everyone else. Mozilla feeling is we like 5043 and would like to take it. Important to note that although they won't be properly saturated, no u32 max, ieee does fix exactly what the real values are. Not a portability issue. Ieee gives the values f32 can represent and it's clear what the largest into an i32 is. Only concern is possibly weird results if you wrote buggy code.
- DN: Concerned about making change, when you get result it's not obvious it was out of bounds value. It being UB in other values is … eh hhhh. Not totally swayed by that. Seen folks doing stuff in ML where they inf and then things just die. Useful to know by looking at data if you've saturated your range. Happens on f16 data, happens possibly on u32 data (haven’t witnessed it). Do get cases of ML models with u8 weights and do dot product and get u32 result. Intuition that I want to see the value was maxed out. Other aspect is the saturated value you get depends on the source type you had. Lets say we add i16 then have conversion of f16 -> i16. Don't know what the numbers are there (6504?) Would rather see all 1bit patterns in saturated result and don’t want to keep in head what source and result are and what the bit pattern is. Not convinced this is a perf problem. Would like to see data that this is important. We took hint with int division and my gut is int division happens more often then f32 -> i32 conversions.
- PM: More colour, think this only impacts signed conversion and only the positive overflow, not the negative. So very specific to one number. Thin if it's u32 the u32 max is a float
- JB: It's not, it's odd, so not a float.
- PM: Ok, that's what I asked in bug, and said yes.
- JB: Definitely not. Just wrong, or there was a misunderstanding.
- JB: I think asking Mike to come back with numbers to show it matters is great.
- KG: We're in the implementations should try things and gather data phase.
- Needs input from Apple
Proposal: fully explicit, non-exclusive "auto" layouts in WGSL (without createPipelineLayout) · Issue #4957
- KG: Still in design phase of this one. WESL folks asking for feedback on a particular idea that they called sharable auto. Mozilla quite liked KNs comment about structs with pointers. Big concern from CW about shareable auto is that it will push folks towards separating modules into different files instead of having in a single file because you cant' have colliding bindings like having something different bound into two different entry points wouldn't work if it had a static use.
- DS: The suggestion from WESL seemed a step backward from what Kai suggested. The need to split into separate files is less nice. Building it into struct seems nicer.
- KG: Interesting to get the feel in the room for what folks like before a proposal is writing. Not sure how high priority this is for folks. Suspect we're in implementation and implementation issue phase and think thats the right thing to do. This is a nice to have that we'll timeslice in when we have time.
- IP: I'm helping WESL with the ts integration and have been discussing internally. Shareable auto was an alternate proposal and not something that we prefer over bindings in structs. Just an alternate proposal that would decrease the amount of surface and supports the bindings statements. Feedback was valid and understand that splitting into multiple files is more of a step backwards then what was initially proposed. Working to figure out how we can do this in userland and what approaches we can do like polyfill. How we can create a better user experience for creating bindings.
- JB: The kind of experimentation that WESL does is extremely valuable. Would be wonderful to have experiments to say we tried and didn't work out as we expected. That stuff is gold.
- Next meeting: Tuesday February 18, 2025, 11a-noon (America/Los_Angeles)
- (Can we talk about:)
- But email Kelsey or the list if you want to meet sooner!