-
Notifications
You must be signed in to change notification settings - Fork 304
WGSL 2022 04 26 Minutes
Kelsey Gilbert edited this page Apr 26, 2022
·
1 revision
🪑 Chair: Kelsey Gilbert
⌨️🙏 Scribes: KG, DS
🗺 Location: meet.google.com
⌚ Time: Tuesday 11am-noon Americas/Los_Angeles
Specification: https://webgpu.dev/wgsl
Meeting Issues: Marked Issues
Open Issues: WGSL Issues
**Todos doc: **WGSN TODOs
Previous: 2022-04-19 - 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
- Myles C. Maxfield
- Robin Morisset
- Daniel Glastonbury
- Google
- Alan Baker
- Antonio Maiorano
- Ben Clayton
- Brandon Jones
- Corentin Wallez
- Dan Sinclair
- David Neto
- Ekaterina Ignasheva
- Kai Ninomiya
- James Darpinian
- James Price
- Rahul Garg
- Ryan Harrison
- Sarah Mashayekhi
- Jaebaek Seo
- Intel
- Hao Li
- Jiajia Qin
- Jiawei Shao
- Narifumi Iwamoto
- Shaobo Yan
- Yang Gu
- Yunchao He
- Zhaoming Jiang
- Microsoft
- Damyan Pepper
- Greg Roth
- Michael Dougherty
- Rafael Cintron
- Tex Riddell
- Mozilla
- Dzmitry Malyshau
- Jim Blandy
- Kelsey Gilbert
- Connecting Matrix
- Muhammad Abeer
- Kings Distributed Systems
- Daniel Desjardins
- Hamada Gasmallah
- Wes Garland
- UC Santa Cruz
- Tyler Sorensen
- Reese Levine
- Dominic Cerisano
- Eduardo H.P. Souza
- Joshua Groves
- Kris & Paul Leathers
- Lukasz Pasek
- Matijs Toonen
- Mehmet Oguz Derin
- Michael Shannon
- Pelle Johnsen
- Timo de Kort
- Tyler Larson
- 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:
- Yes, let’s reserve.
- MM: Probably good
- KG: Post-v1? (yes)
- AB: Maybe not e.g. enums/interpolation attribs, but these are fine for now
- AB: I think this is already covered in the spec.
- Let’s close.
- AB: We should probably use the same language as e.g. OOB access.
- BC: Concern with “impl defined” implies a consistent behavior, and we don’t have that.
- MM: What is the granularity of this? E.g. can multiple runs have different results? Are results different within the same execution?
- MM: “The value of an undefined value would not change from one line to the next” such that we don’t get e.g. undefined branchin.
- JB: THis is something a user wants to know. Like “can I dupe this expr and have it have the same result”.
- AB: I agree that this sounds useful but I’m not sure how I (or MM?) would implement it?
- MM:
- AB: I know how I’d do it in llvm, but not sure about it other backends.
- MM: One solution: “For each expression that can produce UV, I will produce a value”, but if you want to rely on what spir-v has, I’m not sure what spir-v can guarantee w.r.t. UVs.
- AB: I wouldn’t want to have to insert e.g. clamping code after every UV application. I would like to distinguish between cases where we can guarantee it, vs cases where the underlying system has UV issues.
- MM: Less concerned about the portability than the ability for an author to get reasonable logical execution. E.g. skipping branches.
- BC: Not sure if it’s possible to do better.
- KG: Can we call it “arbitrary value”? Then we can rely on normal logical flow.
- MM: Yes that’s cool what I’m asking for.
- BC: Still not sure it’s implementable.
- KG: Can you give us examples where even branches wouldn’t be able to safely give us arbitrary values?
- BC: Yes I’ll find them.
- AB:** Ship it**
- JB: Some examples I ran into. Others tripped over by internal teams. Take those criticism to heart as haven’t put too much thought into these reserved words
- MM: Reserved words are only useful if they can have ambiguity later. For things like buffer can’t see where we could have an ambiguity.
- GR: Spoken about buffer, what about in, out and inout?
- MM: Written often in HLSL, yea?
- GR: Right. Will there be a simillar concept? If not and we’re sure of that?
- JB: Oh, saying we’d like to reserve those as we may want to add those features?
- GR: No so absolute but don’t wan’t to foreclose
- MM: Solution for in/out is pointer
- GR: Want to consider independent of buffer and texture. If we’ve considered and are still good, will go along with that
- KG: Used to in/out from GLSL. In own code for utility use in/out as variable names. Out used a lot. Maybe because of c++ out var. Would like to not reserve and lean in that direction. Will we never have in/out …
- MM: For Metal concept of in/out is not sufficient to describe code needed to generate. Function with in/out and caller calls with thread var and acls again with device variable we have to specialize due to template or copy function. Would have opinions if we wanted to add in/out like GLSL and HLSL have.
- KB: Flush things out a bit, would more prefer to not reserve in/out but still reserve ???. Still have time to add back if we get spooked.
- JB: This PR not intended to engage future language features. Shouldn’t try to decide if we like in/out in language as part of this PR. Would be happy to drop those words from this PR. Already changed internal examples.
- MM: Another path, if we want to add in/out we spell them as @in and @out.
- JR: Right. Same with special attributes on the pointer types.
- KG: Satisfied we’ve though about them to a sufficient degree.
- GR: Yup, just wanted to consider independently.
(5)
- KG: PR from DN. Needs review.** I’ll try to review **…
- DS: Just about moving it down in the grammar, though technically with greedy parsing it’s not a problem just yet. Also we can move it again later if we like.
- Spec needed
- Just waiting on dneto, then ship it
(10)
(15)
(20)
(25)
WGSL should forbid pointers to runtime-sized values as user-defined function parameters · Issue #2268
- Previously
- DN: Working on parser generator/analyzer. which can now determine LL1-ness, but WGSL is not. Not the intent to make it so. Working on upgrading to LALR-table generation.
- Waiting on dneto.
- Previously
- JP: If we’re going with option 2, should have feedback this week.
- JP: Implemented and works as expected. Still has complexity increas with number of function parameters, but we have a limit on those too.
- SPEC NEEDED
- JP: Essentially, the only way two invocations could get different values from a load from the same location, is from a data-race. So the only way it could be non-uniform is if it is a data race.
- MM
- JP: If E’m a shader compiler that’s presented with this case…
- JP: In either of the two cases, do users want workgroup broadcast? I worry that workgroup broadcast isn’t the right tool to tell the compiler that “I don’t have data races in my shader”.
- MM: So you’re imagining a program where an if statement has a non-uniform load. The programmer “knows in their brain” that the load is uniform, but needs to tell the compiler that “I know you can’t prove it, but trust me”, because otherwise it’s slower.
- JP: Yes but I think a user should prefer to load from a read-only storage.
- MM: Well there’s SIMD broadcast, and that’s useful even without uniformity analysis. I think that shows that this kind of broadcast would be useful even without UA.
- KG: Is a “arbitrary value” concept a useful concept here?
- MM: After talking with the Metal team,
volatileis the officially supported way to ensure that UV doesn’t cause UB for bounds checks. That is, when the index being bounds-checked is an undefined value, you can store it in a volatile variable, and then check the volatile variable in the bounds check. Making the array indexing operation conditional on that check ensures that the value produced is not undefined. - JB: Is that written down?
- MM: No
- KG: Just in our minutes now. :)
- KG: It feels like WB is like volatile but for workgroups.
- MM:
- JP: What I was proposing here is to say that loads from writable storage buffers are still uniform. …
- JP: In the spec, underlying APIs define things as UB. Where does WGSL talk about this?
- AB: We defer to Vulkan here.
- JP: I think what I’m hearing is that “practically, these are UV not UB”, and that maybe we can just spec that?
- AB: The UB comes from a complicated place. People think they can “ask for a value from memory”, but lots of things go on behind the scenes that make this much more complicated, and e.g. x != x. It’s because of assumptions the compiler has made, that cause these surprising things.
- AB: If we get to the point where we want races to not be UB anymore, we might make a different decision on this topic.
- KG: Could we use volatile for that?
- MM: We’re sort of saying “data races gonna data race”, so long as we can be safe. Having every load be volatile would be maybe too expensive, but doing it for every array access would be doable.
- KG: So you could get UB, but it’s “safe UB”.
- …
- MM: Probably more than half of WGSL programs will have races somewhere, so it feels too pessimistic to say that these programs are all SOL, we we won’t try to help them.
- AB: Do you think it’s that many programs?
- MM: Yes
- …
- MM: So I’ve described safe bounds checks in Metal. How would you do it in spir-v?
- AB: I don’t know as our guarantee always happens in shader code. Might need hardware requirements.
- MM: Would you require RBAB for WGSL?
- AB: No, but we have other things we can maybe do.
- AB: Spir-v does have a volatile, but it’s not necessarily enough.
- MM: Is volatile required/core?
- AB: It’s core, you can always annotate with it.
- KG: But it might not give you what you need here?
- AB: Certain classes of issues go away with volatile (no rematerialization of loads) but it doesn’t make races go away
- Next week: Non-APAC! Tuesday, May 03, 11am-noon (America/Los_Angeles)
- There is a Chinese holiday next week, so Intel Shanghai would not be able to attend.
- Let’s schedule for the following week, on May 10 for our APAC this month.