Minutes 2022 02 02

GPU Web 2022-02-02

Chair: Corentin

Scribe: Ken/Austin

Location: Google Meet

Tentative agenda

• Administrivia
  • Seek horizontal reviews #2531
• CTS Update
• “Tacit Resolution” Queue
• Non-ratification-track and pre-ratification-track development
  • [Process] Add RequirementsForAdditionalFunctionality.md #2424
  • Add extensions directory and pipeline statistics extension doc #2301
  • Where do we spec WebGPU-WebCodecs interaction? #2498
• Expose WGSL errors in the API #2308
• Consider removing GPUPipelineLayout #2550
• Why are bind group layout fields spelled differently from their WGSL counterparts? #2469
• (deferred) Discuss the WebGPU Adapter Identifier explainer before reaching out to the PING.
• Agenda for next meeting

Attendance

• Apple
  • Myles C. Maxfield
• Google
  • Ben Clayton
  • Brandon Jones
  • Corentin Wallez
  • Gregg Tavares
  • Ken Russell
  • Loko Kung
• Microsoft
  • Jesse Natalie
  • Rafael Cintron
• Mozilla
  • Dzmitry Malyshau
  • Kelsey Gilbert
• Unity
  • Brendan Duncan
• Mehmet Oguz Derin
• Michael Shannon

Administrivia

• CW: talking with our W3C rep, TAG review is not sufficient for going to CR
  • Seek horizontal reviews #2531
• FPWD: Accessibility said "not applicable"
• INTL: have to do a checklist / short form
  • CW: Did this in #2546. PTAL.
• Privacy: we were going to do anyway for adapter.identifier.
• Security. Basically ready, just need to separate security / privacy sections.
• MM: SharedArrayBuffer spec says it's supposed to be behind COOP/COEP; WebGPU has the same timing attacks, so should be behind the same guards.
  • DM: we do have it in the security considerations. Same as ArrayBuffer. If you think we need stronger wording.
  • MM: SAB can be used to manufacture a high-res timer.
  • CW: WebGPU doesn't have a high-res timer.
  • KG: concern it's at confluence of 2 different timelines.
  • MM: shader constantly updating an atomic, and another thread sampling it.
  • CW: let's move this to an issue and discuss it there.

CTS Update

• CW: Kai not here this week; lot of work on WGSL builtin check.
• CW: lots of work on stress tests creating/destroying devices.
• CW: 1D / 3D textures.
• CW: please contribute! It's finding issues in our implementation, so the tests are very useful.

“Tacit Resolution” Queue

• Extend lifetime of GPUExternalTexture imported from video element #2302
  • Might not have a resolution yet
• spec: Last vertex buffer element should not be required to have the full stride size, instead only size of attribs. #2359
• Should GPUDevice.destroy detach all buffer mapping ArrayBuffers? #2545
  • Useful, and doing otherwise would be confusing
• #2554 - have a PR ready, Kai needs to look (?)

Non-ratification-track and pre-ratification-track development

• [Process] Add RequirementsForAdditionalFunctionality.md #2424
  • CW: discussed this internally. Not clear what the goal is. Main concern: what is this trying to achieve? Trying to give guidelines we can show to people outside the group? Something for ourselves? A constraint on what this group can and can not do?
  • CW: we think it needs more clarity. If we want to give guidelines to external people to what can be an extension, we can be more strict even than this.
  • MM: 2 main motivations. First: there are a lot of Vulkan extensions. Makes it hard to write Vulkan code. When discussing float16 in WGSL, there are 4 Vk exts. Makes it hard for authors to use features. First intention here, try to limit the number of extensions we have. One goal, not a ton, authors can write code without struggling.
  • MM: Second: attempt to limit fragmentation. Didn't want a set of extensions 1 browser supports, and another browser doesn't (and supports a different set). This would create 2 ways of writing WebGPU code - an anti-pattern on the web.
  • MM: If you take that to its limit, would mean no extensions - that's clearly going too far.
  • MM: goal here: have relatively small number of extensions, and have those shared & collaborated on, not siloed.
  • CW: thanks, that makes the intent clear. Nobody likes extension soup. In float16 case, that's why we suggested having 1 extension doing everything.
  • CW: we do already seem to be going toward extension soup. IndirectDrawFirstInstance, for example.
  • CW: maybe after V1 we come up with a notion of feature level - these extensions all come together.
  • MM: we have the same thought. Separated this doc intentionally into pieces. There would be additional changes built on this doc in the future to add more requirements. Initial doc, we think, is fairly loose - fairly easy to meet these guidelines. Separated out more conflicting items into a separate doc, not posted yet.
  • CW: would it make sense to say this doc's not for an extensions/ directory, or more - what it takes for an extension to be considered to go into the living spec for WebGPU?
  • MM: think that question's separate. One issue: what are the extensions we want to standardize? And what docs can live in our repo? This doc attempts to answer both of those.
  • KR: That language caused some concerns on our side. It seemed too strong by just shutting down discussions about some features. "Can we do X" "Nope because of rule N"
  • MM: the example you gave satisfies this argument - 2 classes of devices. Agree with you that open-field discussion is valuable, should allow it. As a feature that aspires to work on multiple vendors / platforms; would be legal. Not allowed - I want to expose a Metal-specific feature, no plans/expectation that it'd be exposed on anything other than Metal.
  • KR: Still a bit concerned that prototyping can still be single vendor. Ray tracing not quite single vendor anymore but still it would be most useful to prototype future looking features like these and preventing discussions about these is too harsh.
  • MM: not squelching discussion - squelching discussion in these meetings. Office hour discussion is OK.
  • KG: what is the desire for the explicit rule here?
  • MM: it's defensive, for the expectation that some GPU vendor may come along - even Apple - saying we need an Apple-specific feature, please add it to WebGPU. Fundamentally counter to the ideals of the web.
  • KG: understood. But when we bind ourselves to these rules, we can also unbind ourselves - putting a roadblock in place, with language that we can ultimately override.
  • CW: WebCodecs - an example right now, only 1 browser supports it, Chromium would like WebGPU integration. Maybe FF will support it - not sure. There's a <model> tag group / explainer from Apple - if there's 3D on the web it'd be great if WebGPU could work with it somehow. Would still be somewhat useful - if only a single browser supports the <model> tag, would like conversations to be able to happen here, if WebGPU has to integrate with it. Similar conversations about WebNN and integration. Seems like a natural place for these discussions to happen.
  • MM: all the examples you raised would be fine. This doc doesn't label implementations as required to discuss something. Both WebNN and WebCodecs and <model> element are all standards intended to be implementable on all browsers, so they pass the test. Don't want an NV_ prefixed extension.
  • BJ: the document uses "implementable" a lot - don't see "implemented". Even if only 1 browser's implementing it right now, or one platform has it - fact that it's implementable elsewhere has weight. For Myles: the exact text here seems fairly OK - I think these are principles we try to adhere to anyway as a web standards group. Discussions in the past - something not supported on all hardware, so we won't expose it to the web. You've been careful not trying to pinpoint cases here - it sounded like maybe there was an example out of WebGL that sparked a concern here - is there a target scenario you were hoping to avoid?
  • MM: yes. Scroll down the extensions list in the Vk registry, see how many of those are device-specific - and imagine web developer trying to use an AGX_ prefixed extension. Later, an AMD_ extension that does the same thing, slightly differently. Awful from web developer standpoint.
  • BJ: there are definitely lots of Vk extensions. Somewhat by design. DOn't think anyone thinks that should be carried to the web. Similarly, WebGL vs. OpenGL/ES - lots of vendor extensions. Comparing list of OGL exts to WebGL, WebGL's is a much smaller list. Not aware of any that target a specific piece of HW, platform, NV_ or AMD_, etc. extension. Understand the concern about not wanting to pull everything from the native side. History has generally been considerate of the web developer. History of problematic past graphics development on the web? Trying to avoid a repeat?
  • MM: not such a thing on the web. Sounds like you and I are agreeing with each other.
  • BJ: generally yes.
  • MM: so there's discussion - if we all agree, do we need to write it down? I'd say the answer is yes. In the future, we expect proposals that break this tacit understanding, want something written down that we can point to.
  • DM: we've had a few issues like that. Why are we discussing this if only exposed to one vendor or API? I'd like to be able to refer to these rules, even if someone else is doing the work. Another example: one API comes up with a feature, if we're exposign it in WebGPU then another API can figure out a similar but different way, and don't want to end up in that situation. Ray tracing's one example. Mesh shader is another. Don't want to rush tese.
  • MM: variable rasterization rate is another one. Formulation is different in 3 different backend APIs. Would be bad if we had 3 extensions.
  • MM: other WGs write down their design principles, so it's not unreasonable from that standpoint.
  • CW: sounds like we're all in agreement. Like Kelsey said - this doc's a guideline, and not binding - if we enforce rules, we can un-enforce them. If we're going to write these maybe we should be more strict. Maybe say, implementers should say it's reasonably implementable on all browsers? Be more clear/strict about these.
  • MM: think that's right. Implementability isn't defined - feedback from internal colleagues too - putting a bit stronger guardrail on def'n of implementability would be good.
• Add extensions directory and pipeline statistics extension doc #2301
  • CW: these are implementable on all APIs. Seem to satisfy the requirements of the abovementioned doc. Are they in a .md file in an extensions/ directory? Just an explainer?
  • MM: don't see why extensions should differ from other feature discussions. Think they should just follow that.
  • CW: spec's been a living draft for now. As we go to CR, maybe be more careful - it'll be the WebGPU spec and ppl will go to editors' draft more? Makes sense to have nursery for new proposals?
  • MM: CSS WG makes snapshot periodically. Look to snapshots for stable ones, otherwise look at live up-to-date doc.
  • KG: proposal then - this extension will be in the standard? Is that where we're heading? Philosophically different direction.
  • MM: thought discussion was - ppl come to us, please add this feature, we think it's a good idea - what buttons mechanically do they click in Github to do that.
  • CW: raytracing for example - will take many iterations. Trivial ones can go directly into spec, but a place to put larger features for discussion / incubation is imp't.
  • KR: in WebGL it's been useful to have an incubation space. Agree with having an extensions/ directory based on experience.
  • KG: sounds like a branch. Don't want people writing demos based on explainers in our repo where we know it's not the thing we're going to standardize on. Want it to be obvious when a presentation's done, but the feature's not baked.
  • CW: "drafts" directory then? Multiple browsers can prototype impls to make sure the idea works?
  • BJ: some prior art in different W3C group is Immersive Web group. Proposals repo under IW group. A readme walking you through what's expected. Proposals for new API features we direct individuals and implementers to go through the incubation process. If it has support, want to move it forward - create its own repo and move it forward. Don't think it's a bad idea - has produced good features for the API in the past. Don't really have extensions, but in complementary specs, or core features of the primary spec.
  • CW: sounds workable.
  • MM: KG are you worried about situation where there's a doc in a folder and is in-progress, unimplemented, expected to graduate? Or a doc in a folder, not expected to graduate into main spec, just there as a browser-specific detail?
  • KG: cases where one party has a prototype impl, there's an explainer, but to someone watching a presentation on it, looks like the future. Other parties in WG might have reservations. Want to say, this is still under active discussion.
  • MM: current procedure is for those ideas to be in issues, and they aren't in any spec. Imagining a drafts/ folder, do you think the WG should have a process for moving a proposal into drafts/? In TC39 and CSSWG, the answer is yes - group has to agree to work on a proposal.
  • KG: think we need WG consensus to put something into the repo, yes. Something imp't to clarify.
  • MM: think there's a path forward then. 1) Someone files an issue 2) WG discusses the issue. If a big issue, goes into doc in folder - if small, goes into a PR. 3) If doc in folder, there'll be another WG resolution to migrate into the spec.
  • CW: seems to be exactly what process is in Immersive Web WG.
  • KG: seems fine. Don't feel it's that imp't to write that process down when to move things in/out. Trying to solve problems in front of us - we might say it's imp't to have this in a draft for discussion. Don't want to add process to those cases, to dictate which direction it goes. Useful to have drafts/ dir. Need WG consensus to put things into the repo. Everything else follows. I prefer light processes.
  • MM: do you think a folder's better than a branch?
  • BJ: it's more visible, esp. on Github. Harder to see what branch you're on.
  • CW: and also merge conflicts.
  • MM: not sure I agree with that - it's at the top.
  • KG: think it can be useful to have a drafts/ folder. As a WG we can decide what goes in there.
  • CW: and a guideline, if it's a big feature, it goes through a draft phase.
  • MM: sure, OK. Should be written down that new docs in drafts/ folder need to be approved by CG, and also should write down - new additions to spec need WG resolution.
• Where do we spec WebGPU-WebCodecs interaction? #2498
  • KG: think this is tricky, we're not sure what form it takes in other browsers yet. Hypothetically - feature A is a one-implementer-only thing. Where do we spec the interactions of that feature, and an API that's consensus driven and cross UA?
  • CW: kind of the same question as WebNN. Has interactions with WebGPU, but how do they sort this out?
  • KG: not sure. Tricky part in WebCodecs discussion - hard to make good decision in such an abstract scenario. Part of WebGPU design - what will we implement, how implementable is it, how does it fit into our story. If we don't know we'll implement it - becomes a rubber stamp if we say "yes". Concern - if we do end up implementing WebCodecs and have new impl concerns - might have different decisions between WebGPU & WebCodecs. Just don't know today because we don't have a WebCodecs impl. Part of the question is, where do we spec it, and who specs it and can we spec it? We can technically spec this in WebGPU, just really hard for an impl that doesn't have an impl to sign up for it.
  • MM: situation described here is true for any standardization process. Apple’s WebGPU implementation is nascent compared to the other browsers, but still here trying to make good decisions for our platforms. If it's true that a browser will ship support for a feature - it'll be standardized, and you're either in the room or not. You can't tell another browser to stop shipping something because you haven't written your impl yet.
  • MM: Also, WebCodecs would pass the test according to the first topic. It aspires to be implementable everywhere, reasonable to add to the WebGPU spec.
  • MM: It is optional, though, so it should be labelled in the spec as optional, just like we do the other optional features.
  • KR: About WebCodec specifically. All browsers have been involved in the discussions for WebCodec. The form of the API is stable. The only question is do we add a union type with the VideoFrame for importTexture and what is the lifetime if you close to the VideoFrame. Should all be pretty uncontroversial if we already have HTMLVideoElement import. WebGL already has WebCodec in texImage2D, so would like to see the data type show up in the IDL. If the browser doesn't have WebCodec then you can't create a VideoFrame and can't pass it in the first place.
  • KG: Concern was that it was easier to sign off on WebCodec as a texImage2D than as GPUExternalTexture. Different complexity and criteria.
  • KR: let's table, we're out of time - but again, WebCodecs has already gone through the standardization process.
  • KG: I'll reach out to our WebCodecs folks.
  • MM: imagine Chrome implements it one way, and say Gecko wants to implement the same thing in a year and finds that matching Chrome's behavior is hard. What would you like to have happen?
  • CW; it's a web compat risk. We probably add a second path that works in both browsers.
  • KG: that's the concern, that it'd be a painful workaround.

Expose WGSL errors in the API #2308

Consider removing GPUPipelineLayout #2550

Why are bind group layout fields spelled differently from their WGSL counterparts? #2469

(deferred) Discuss the WebGPU Adapter Identifier explainer before reaching out to the PING.

Agenda for next meeting

• CW: Adapter identifier explainer. Let me know if we need more time.
• Carry over the agenda from this meeting.
• VF2F is next week. We'll make an agenda offline.
• KG: please fill out the WebGPU survey!