GPU Web 2023 08 30

GPU Web 2023-08-30 (Atlantic-timed)

Note that unless stated otherwise this is a GPU for the Web community group meeting and not a working group meeting.

Chair: CW

Scribe:

Location: Google Meet

Attendance

• Apple
  • Myles C. Maxfield
• Google
  • Austin Eng
  • Brandon Jones
  • Corentin Wallez
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
  • Stephen White
• Microsoft
  • Rafael Cintron
• Mozilla
  • Kelsey Gilbert
• Nvidia
  • Anders Leino

Administrivia

• Nothing today
• (Milestone discussion later.)

CTS Update

• KN: Brandon just fixed some broken tests which had some cases that were just wrong. WGSL tests in progress.
• KN: optimizations on case iteration in the suite, esp. single case at a time. Think the last fix is now in. Should be working the same way as before, but slightly faster.

“Tacit Resolution” Queue

• Empty! Woo!

Milestones renamed

• Milestones have been renumbered and defined according to the tentative discussion from Aug 9. Milestones
• KN: (1) Do the names and definitions sound good? (2) I think we’re going to need to do a full re-triage exercise but if we aren’t getting through that soon then the editors volunteer to finish triaging the now-deprecated “polish post-v1” milestone into milestones 0/1/2 based on past discussion.
• KG: Not complete consensus, but the direction we want to go. If instead we called it "Milestone N" we called it "untriaged future stuff we don't want to work on right now", we might call it "Milestone 3+" - want to re-triage later, when we go into Milestone 3.
• KG: don't care particularly strongly. Either way is good. Core idea - if we know we'll work on something in Milestone 2, we'd work on that and put things in it. And try to triage things into milestones more aggressively. Concern: medium-sized fix for the future, wanted to do for Milestone 2, but we forget about it because we have so much untriaged stuff.
• MM: Milestone N -> 3+ renaming sounds fine. Triaging going well - people can move things fluidly between milestones, don't want to add more structure to it. In milestones, there is one "Polish-Post-V1 (deprecated)" - one of the renaming's goals is to move things out of that milestone. What's the right mechanism for that? Least friction - editors go through, do their best to categorize, other people help fix. Other ways, but suggest that way of doing it.
• CW: thumbs up
• KG: sounds fine. Should put more work into closing Milestone-0 issues.
• KN: great.
• CW: OK. We do keep Milestone 2 then as the next milestone.
• KG: my proposal, but not super attached to it - move everything in Milestone 2 to Milestone N, rename Milestone N to Milestone 2+, and re-triage things into Milestone 2. Want to default to putting things earlier. Should be fluid to move things from 2 to 3.
• MM: in 5 years we'll have Milestone 7/8/9 etc. Do those make sense or should we have "current", "next", "future"?
• KN: I like having 7/8/9.
• KG: I like having fixed numbers. They mention points in time.
• KN: milestones on Github can be closed as they age out.
• KG: might put a year on them?

Extended brightness range rendering #4239 (please read beforehand)

• Tabled for this meeting, until out-of-band meeting happens.

WebGPU Compatibility Mode #4266** **(please read beforehand)

• MM: (Is it possible to defer a week? There’s been a lot of good technical discussion on the GitHub issue, and Mike won’t be able to join the call today and I’d like him to attend the discussion.)
• CW: some clarification on positions would be good to have.
• KN: MM, BJ and I chatted on Monday to understand our positions. Want to be able to make palatable proposals. Came away with q for MM: think it's your position that if we make a compat-mode that adds add'l restrictions that's opt-in, that we won't be able to unship it later. That's a key component of the compat proposal; it's what makes it work in our opinion. Want to understand better what the issue is, and see if it can be mitigated / resolved.
• MM: philosophy here is that nothing can be unshipped. Proposal here is to add validation - every valid compat program is a valid WebGPU program. I understand that. If you have a mode switch, mode switch needs to live forever. (On the web?)
• MM: we think the mode switch will have to live forever, and likely the validation, too. 2 other reasons: (1) fragmenting the ecosystem - unfortunate. (2) doesn't make sense to us to standardize something that will eventually go away.
• KG: reasonable concerns. Would like to address them. Moz's position - for something restrictive like this, we feel we can unship it. Never being able to unship comes from not having forward compatibility. Need to take care to do things in this way. It's a requirement for Moz that we be able to unship them. E.g., getting rid of restrictions in WebGL - something we've done, not unreasonable.
• KN: was going to say basically hte same thing. If it's our opinion that we can't remove restrictions, it's something we've wanted to do in the core APi as well. Are you saying we shouldn't do that? E.g. moving a feature into core when it's ubiquitous?
• MM: sidestepping that a bit - would help us if there was some precedent that was also a mode switch. Web started with some set of features. Classes in JS were an error for example. Then classes were added to JS, some invalid programs became valid. Not a mode switch so much as a feature addition. Is there any precedent for a mode switch on the web platform?
  • KN: examples of WebGL extensions moving into core?
  • KG: no but it's mainly our laziness. 🙂
  • BJ: were done in the migration from WebGL 1 -> 2, but not the same.
  • CW: things related to [SecureContext] and Spectre for example.
  • MM: having to switch to https?
  • CW: partly. Also some functionality gated behind cross-origin policies. Chrome-specific security policies, or standardized?
  • KN: COOP and COEP are standardized, as is their need for using SharedArrayBuffer.
• BJ: talking about designing an API for unshipping - I view this as a super-polyfill. Polyfills exist to be replaced.
• (KN: think even if there isn't a precedent, that we could ask the TAG or our individual company web platform leads.
• KG: think it'd be more efficient to ask ourselves, do we even need to answer this question about precedent.)
• BJ: MM is saying it's a mode switch we're introducing - yes, insofar as it turns on validation. Long term it'll be seen as more of a hint - the class of devices you want to run on. We can see a day where there wn't be a significant share of devices on the market that need this. Then if you turn off the need for compat, nobody will notice. Nobody will file a bug in response to it. All of the validation we were doing could disappear - wouldn't break anybody except maybe some CTS tests that were looking for it to fire. Think it can be viewed as more of a hint. "I want to be able to run on this set of devices."
• SW: validation is a developer tool. When no longer a significant number of devices, it's not hurting any developer to say, this won't work on devices that don't exits.
• KG: that's the goal. Having even an oversimplified strawman proposal could help - e.g. a basic form of this. Some constraint you're opting into. E.g. depth-6 texture arrays in compat mode, you have to tell us it's going to be a cubemap. Could consider that and think, do we have a path forward for doing that kind of validation? And removing that one thing later? Then later, by induction, this thing works.
• CW: are you suggesting we explain what WebGPU-Compat with a single constraint would look like?
• KG: if you can convince the group that Compat with 1 constraint can be reduced to 0 constraints, think would be helpful.
• CW: Compat investigation has a lot of detail of what was possible & not. Maybe some signal being lost in its length. This is polyfillable, this isn't, solution for this is to polyfill, and it's cheap.
• SW: don't think the workarounds/polyfills will impact the spec.
• MM: raised point with Kai that want to repeat - number of features polyfilled isn't binary, it's a sliding scale. Amount of fragmentation is also non-binary. Core disagreement - one group says a certain percentage of features should be polyfilled, and other group says a different percentage should be. Compromise is possible. If APIs are close enough that fragmentation is minimized, we think it's helpful.
• KG: at this point, speaking to complexity of proposal - think we need a proposal doc that's separate / updatable rather than resynthesizing from the comments. Google Doc, HackMD, some alternate form. Update the original message? Unclear what the consensus is.
• CW: can be fixed.
• KN: had this in spreadsheet before.
• KR: think the request is for a more terse proposal doc too.
• KG: we can start a PR for this, too. Some live doc.
• SW: one part that's binary is - should we have a mode, or not. Could motivate answer by - here's something that's hard to polyfill. And discuss that. If there's something we can't emulate, I think we need a Compat mode.
• KG: feeds discussion but doesn't compel. I think whether we have a mode switch is unclear - to the point because we disagree on whether we can get rid of the mode switch.
• CW: think idea is - find one thing that's not polyfillable, and discuss it in terms of Compat mode. Figure out how it wouldn't break applications. See from that point. And better categorize other solutions.
• KG: given today's feedback, think satisfying more of that feedback would help.
• KR: earlier in WebGL’s development, we had to support desktop GL x.x. There were significant complexities targeting those APIs. That hardware aged out - no significant number of users on Intel HD 3000 for example. We have evidence that aging out does happen, and are confident that in the fullness of time, the number of devices that need compat will go to ~0.
• MM: argument that this validation can be removed has been made many times. I understand the argument. Don't want to agree to this now, since my co-workers aren't in the room.
• CW: let's think more about the points here and discuss next time. I personally won't be in the next meeting because it's APAC-timed. Maybe tabled for two weeks?

Agenda for next meeting

• Please add agenda items.
• Agenda for next meeting (Pacific-time)
  • WebGPU Compatibility Mode #4266
  • Render to 3D texture
• Schedule once subgroup has had a chance to meet
  • Extended brightness range rendering #4239