-
Notifications
You must be signed in to change notification settings - Fork 304
WGSL 2022 10 18 Minutes
πͺ Chair: KG
β¨οΈπ Scribes: KG
πΊ Location: meet.google.com
β Time: (APAC!) Tuesday **4-5pm **Americas/Los_Angeles
(Check your timezone: https://www.timeanddate.com/worldclock/fixedtime.html?msg=WGSL+APAC+Meeting&iso=20221018T16&p1=137&ah=1 )
Specification: https://webgpu.dev/wgsl
Meeting Issues: Marked Issues
Open Issues: WGSL Issues, Outstanding V1 Issues+PRs
**Todos doc: **WGSL TODOs
Previous: 2022-10-11 - 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
- Myles C. Maxfield
- 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
- Microsoft
- Damyan Pepper
- Greg Roth
- Michael Dougherty
- Rafael Cintron
- Tex Riddell
- Mozilla
- Erich Gubler
- Jim Blandy
- Kelsey Gilbert
- Connecting Matrix
- Muhammad Abeer
- Kings Distributed Systems
- Daniel Desjardins
- Hamada Gasmallah
- Wes Garland
- UC Santa Cruz
- Reese Levine
- Tyler Sorensen
- Dominic Cerisano
- Dzmitry Malyshau
- Eduardo H.P. Souza
- Jeremy Sachs
- Joshua Groves
- Lukasz Pasek
- Matijs Toonen
- Mehmet Oguz Derin
- Michael Shannon
- Pelle Johnsen
- Robin Morisset
- 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:
- WGSL Only: https://github.com/gpuweb/admin/pull/19
- We will be doing more APAC meetings during Nov and Dec.
- We are also moving APAC slot one hour earlier (4pm Americas/Los_Angeles), though this will drift again in early November with USAβs timezone change.
- DG: Looked at ldexp in stdlib, defined to return HUGE_VAL for error conditions. Talking internally, we think we need something like this for a frozen value, so that we can test about it.
- AB: Thereβs PR#3508, which I think does describe a solution like that for βindeterminate valueβ.
- DG: Do we expect to define this val?
- KG: Implementation defined.
- JB: We want to ensure that e.g. Inf is still valid if supported.
- Waiting on DN to merge #3508.
- Myles still needs to make a PR. Can we defer this?
- Yes, defer
- -> Post v1
- JB: Thereβs no clear perfect relationship between limits in our target langs and wgsl source, so we should probably pick min of the target langs and divide by 2.
- AB: We can fall back on Spurious Error too.
- KG: We are just picking something to test, where we say βsomething at least this complex worksβ
- Letβs take 127, and βany control flowβ, not ifs specifically.
- (PR for issue #3530).
- JB: I trust DN to implement this.
- DG: To clarity, this is indeed changing the tightness of e.g. function call vs pointer deref parsing to closer match other langs?
- AB: Thatβs my understanding.
- DG: It looks like no actually, that this would diverge us.
- KG: DN writes that we could look into #1580 if we wanted an alternative
- JB: Because we donβt allow pointers to interiors of structs, the usual Rust/C parse is not useful: p[0] can never be a pointer. And given that we do want to use pointers then even though we would theoretically diverge, we probably donβt have any issues here in practices.
- DG: +1, I want DN here also
- Tabled
- AKA βfunction-out-param language functionalityβ
- See also:
- JB: Moz is ok with the group consensus last week:
- 1.0 leave spec as is today
- With understanding that weβd expand this in 1.1.
- Specifically, weβd use native constructs where we can, and on systems that donβt support this, use the Clayton Transform.
- JB: We think this is a solid compromise, especially if we can defer implementation complexity.
- AB: Awesome. But also, βleave as isβ includes merging βban workgroup pointersβ
- MM: can we add a 1.1 milestone?
- KG: I will make one
- RC: Had TR review, his Q, what if we have different modules compiled at different times? Does this make it harder to reason about?
- AB: Youβd need to see the whole module if you need to do a transform. Nowhere that doesnβt support smarter pointers is going to require this transformation.
- TR: Yeah, my concern was just for when modules might be compiled separately. Specifically what [thing] was written to, and that we donβt have [thing] across module boundaries.
- JB: Difference between being able to validate separately, vs emitting code separately.
- TR: My understanding is that you canβt have two function args, that are both pointing to the same root ident. But that β¦
- JB: What analysis says right now, is that itβs not just about the function, but also cares about its callees.
- TR: Yeah so youβd need new metadata about callees I think.
- JB: We donβt have separate compilation right now, so we donβt know what that would look like, and so itβs hard to speak to any problem there.
- TR: Ok
- MM: +1 to JB about how we would approach this.
- TR: One more Q, a little confused about aliasing rules: If you have pointer into aggregates, it seems like you should be able to, but couldnβt find example except indexing an external buffer. I was wondering if you can point into two points within an aggregate?
- AB: You can make those pointers into aggregates, but you canβt pass those into functions according to spec.
- AB: Iβd like to get MM to clarity which carveouts MM wants us to remove in 1.1 specifically.
- MM: Sure.
- Alias analysis, I donβt know enough about the Clayton transform to know if if preserves the order of writes and reads. If you have two pointers and they do alias, does that change their order.
- BC: Implementation on HLSL, aliasing for
inout
is still a hazard, so I propose that we keep that restriction in 1.1. - MM: If we keep that, imagine we have array, and you have an index into the array, but you canβt know if two of those would point to the same part of the array, so weβd still need to prevent that?
- BC: Maybe? I could see how it would be annoying if you wanted a swap function to e.g. swap two elements of an array by pointers.
- AB: You wouldnβt necessarily know if e.g. two dynamic/runtime pointers had the same target.
- BC: Thatβs part of the βshapeβ of this.
- KG: I would like to see more examples if
- MM: Are we going to relax the restriction against subobject pointers?
- AB: Yes, but you still couldnβt pass in two subobject pointers to the same object.
- MM: so this is a pessimal analysis here, where weβd forbid just in case.
- Merge ban-ptr-to-wg, and add v1.1 milestone (#3422)
- KG:
- MM: I wanted to mention that if we need UnAn for security, then we canβt give an opt-out here. There was some talk that this might be the case (during office hours?), but we need to find out. I think need to figure out if we do need this.
- BC: We did talk with one partner and asked to be able to publish/share some of their shaders, and in the mean time weβve agreed to drop Chrome back to UA warnings instead of hard errors.
- BC: One issue seen is that scalars which require separate uniformity tracking are being packed into vectors as part of earlier shader pipelines. The spec doesnβt currently track uniformity across vector lanes, but it could. Even with this - there are cases in our partnerβs corpus that wouldnβt be solvable by adjusting the UA algorithm - we need **_an _**escape hatch.
- AB: One major fix, was when I added the value assignment, where if you reassigned an aggregate, it could become uniform again. However, we do think there are cases where thereβs just no recourse that we can analyze.
- AB: We think that we need some kind of escape hatch though.
- AB: To MMβs point, I donβt know how to give proof of security here, but it would have to do with e.g. what we do for indeterminate values.
- JB: One reason this convo this will be a little odd, is weβre not just talking about what changes we make to the spec, but weβre also talking about how to relate to committee membersβ partners. Weβre on the verge of getting super valuable feedback from authors. Particularly, we want to get this valuable information out of people hitting, and we want to do it without being insincere.
- AB:
- KG: While it makes sense to give partners a temporary carve-out so work can continue, we donβt want them to show up in three months after weβve done everything we can and say, βwe still need a global opt-outβ. Ideally, we want something like Rustβs
unsafe
blocks, where you can mark one section as βtrust meβ, but still get the benefits of the analysis from other areas. But we still want feedback from them on what are the actual issues that people are running into, so we can fix them for other people. It sounds a bit like they donβt want to fix the problems, they just want the analysis to be turned off. - AB: This partner did post specific issues, and they did explain the parts that donβt work. Theyβre not just saying, βturn it offβ. Weβre not proposing a global switch, weβre open to a range of possibilities from the broad to the specific
- KG: We want the client to feel heard, but we also want to make sure that we can move forward by hearing more about the shaders that fail. We want to unblock them in the short term, but we need to get the feedback about the details
- MM: One lens to view this discussion: Should we track vector members independently? yes/no? Should we split variable lifetimes at assignments? We knew it was a likely request, here it is. Discard is already fixed. Should we add a uniform load function? Now we have a request for that. One way to avoid heated discussions is to address the concrete requests that we already have.
- KG: Yes - we want to collaborate. I didnβt know that those things were specifically asked for, because they were not stated directly in the issue.
- AB: We can make the analysis more accurate, up until we run into similar problems to those that arise with alias analysis, where the results depend on runtime behavior. They have issues beyond what is reasonably solved by the analysis. For example: they sample a texture, and based on that they choose which texture to sample. The issue has gotten long, and these specifics are hard to find. Weβre working on getting the details from them. We all agreed that we wanted uniformity analysis, and weβre committed to make it work, weβre not abandoning it
- KG: We just need to concentrate on specifics here.
- MM: Iβm not sure that having an opt-out is better than just not running the analysis, but we can leave that for another discussion.
- Next week: (non-APAC!) Tuesday, October 25, 11am-noon (America/Los_Angeles)
FYI:: Merged. https://github.com/gpuweb/gpuweb/pull/3539 wgsl: Fix how we say concrete left shift must not overflow (if known before runtime) #3539
- Fixes a drafting error from before.
Allow signedness to differ between integer texture builtin arguments (C template) #3536