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

Chair: KG

Scribe: KR

Location: Google Meet

• Administrivia
  • Moving to CR
  • Rechartering to make WebGPU + WGSL a living spec
• CTS Update
• “Tacit Resolution” Queue
• Resurrect vertex formats dropped for macOS < 10.13 #4549
• Add extended range #4500 (issue #4239)
• DrawIndirectCount #1354
• Synchronously query GPUAdapterInfo #4536
• (stretch last minute addition) Resurrect vertex formats dropped for macOS < 10.13 #4549
• Agenda for next meeting

• Apple
  • Mike Wyrzykowski
• Google
  • Corentin Wallez
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
  • Stephen White
• Mozilla
  • Jim Blandy
  • Kelsey Gilbert
• Mehmet Oguz Derin

• Moving to CR
• Rechartering to make WebGPU + WGSL a living spec
• François Daoust says - do the latter in parallel to moving to CR. Living spec is somewhat CR-based. Exit criteria isn't "produce a publication and done".
• Things that need to be done:
  • Feel there are no glaring holes in the spec
  • We have a lot of issues still outstanding. But most of these are triaged into milestones further in the future than we're focusing on.
  • KN: M0s - some editorial stuff that may need to be integrated, but these have been discussed.
  • Need to integrate these or move out the milestone.
  • KN: there are some which are bugs, but some are still open.
  • KG: preference is to just specify these. Asking editors to focus on that. Anyone else is welcome to contribute, too. :) Will make sure we have a clear set of tasks in M0.
• Once we're satisfied with that, we decide to do that as a WG. Not in today's meeting, but in an upcoming one.
  • Will trigger a bunch of processes, including sending a snapshot back to companies to do legal checks, etc.
• CW: do we need to fix up all the editorial issues in M0? We have a lot, but very few non-editorial ones. Those, we need to close or move out. There are ~120 editorial issues.
  • KG: need to be satisfied that the spec's "done". Need to make sure these can be moved to a further milestone. Just need a milestone that we consider "done".
  • CW: guess we can move things to Milestone 1.
  • KG: not "when do we want these" but "when do we need these".
  • KG: we have a broad definition of "editorial". Decided to make this change - exact wording is editorial - but that's not really an editorial change. It's a substantive change to the spec that we delegate to the editors.
  • KN: right now there is an issue tracker for true editorial work but you can't see it in the issue list. We did actually distinguish between editorial work and "things that need to be thought through and written down".
  • KG: in WGSL we use different labels. WGSL-Resolved and Editorial. Probably what we should do.
  • CW/KN: agree.
  • KG: milestone triage - I ignore everything "editorial". Should be small, non-substantial stuff. So some work to do here.
• KG: concerns about moving to CR?
  • CW: think everyone's agreeing to move to CR, but there's also the topic of moving to a living spec.
  • KN: one q - what timeline? I don't foresee having enough time to do all the stuff I'd like to do before CR.
  • KG: we have to do the things. We were supposed to have done these before anyone shipped. Shipping happened before that train instead of behind it. So this is something that must be backfilled.
  • KN: that it should have gone to CR?
  • KG: yes. W3C documentation - that's the stage when you're ready for impl feedback. When you think the spec's ready. That's the strict reading. This is a kind of project where we had to do a lot of impl work to understand the ramifications of the spec. We somewhat ignored that and need to fix it.
  • CW: we'll fix it - don't think there's a big rush - the CR process takes a long time anyway.
  • KG: Moz doesn't really want to give more standards feedback until we get to CR.
  • KR: what are the potential timelines?
  • KG: 30 days min, probably 60 days. I'll do my best to triage things from M0 into M-laters. But then need to draw the rest of the spec. That's needed to get to CR. It doesn't mean we're "done" - just close to what we think we want. It doesn't need to be perfect.
  • KN: for both WD and CR - say the same thing about implementations. So those two stages seem the same.
    • https://www.w3.org/standards/types/
    • These documents MUST NOT be cited as W3C standards and may or may not become W3C standards.
    • Software MAY implement these specifications at their own risk but implementation feedback is encouraged.
  • KG: for impl yes - for shipping not.
  • KN: think that's what they mean?
  • KG: from Moz's standards team and our AC rep - their position is that WDs are not standards.
  • CW: guidance from our standards folks - we can ship before CR if we're confident in the shape of the API. Because CR takes a long time to get through.
  • KG: doesn't match what we've heard on our side.
  • CW: maybe Moz/Chromium API folks have different views on this. We do want to get to CR anyway - for interaction of impls with each other, causing friction because it isn't CR - so let's go to CR. No need to debate what should be done.
  • KG: we need to move pretty quickly to CR. There are requests for standards positions - have discussed with Moz's AC rep - they're asking what is going on. Yes, should go to CR. No, doesn't need to be perfect.. Don't ask for standards positions before CR.
  • CW: we'll have to check with Chromium's standards folks.
  • …more discussion…
  • KG: process for CR says "you should not have open issues against the spec". I don't plan to get to that criterion - just no M0s open.
  • CW: 2 issues, the timeline we want to get to CR, and the interaction of standards processes among browsers. For WebGPU this is breaking down a bit; we'll prioritize going to CR so the problem disappears.
• Living spec discussion
  • CR model - need to define exit criteria for going to recommendation. Now - this is no longer a requirement. Have a CR that doesn't have an exit criteria. Then keep publishing versions that define what the living spec is. Suggest that we move WebGPU to this model. Additions, extensions, all fit better in this model.
  • KN: only other alternative would be to freeze the spec and put new stuff in a new spec - don't want to do that.
  • KG: there isn't actually an option for that. If we want to keep adding things to the spec we need to keep CR snapshots (?) - not sure.
  • KN: more, a second spec that goes to CR.
  • KG: freezing the current spec - would be at a certain checkout. Once approved, we have a list of things going forward past that in the working draft.
  • KN: What’s the difference between Living Spec and just periodically pushing new CRs?
  • CW: could ask fdaoust@ to explain this.
  • KR: WebIDL had a working draft that published CRs periodically and it was very confusing because there were two very different versions of the spec, one very out of date.
  • KG: think the thing you want from a living standard doesn't exist, but point well taken. Should not have things that are very out of date.

• WGSL CTS - Trend looks good!

• VideoFrame should use display size, not coded size #4525
  • KG: coded size likely to be larger than display size. Likely to be rotated w.r.t. display size. Might have unusual scaling, etc.
  • At WebGPU's level - with developer guarantees we're giving to users (video frames are simpler than reality) - think display size is correct. Was enough to make me nervous. Two things - if you're copying from this image to something, it's strange - it's more than a copy, more like a resolve operation. Gives you something different from the input as the output. And for external textures in WGSL, you can sample them with uber-sampler but also textureLoad them - saying you textureLoad but don't operate on the coded size makes me nervous. Not sure why we added textureLoad from external textures…
  • GT: feels strange to not just get the data, but rather some interpolation of the data. And if you want to get back to the original data you can't because it's been manipulated. The data inside a video isn't necessarily color data. Like Kinect 3D data. If all info was there - here's what is needed to display it correctly - would be easier.
  • KN: would be more advanced usage of WebCodecs' VideoFrame. VideoFrame can give you a lot of raw stuff about the frame. We can iterate on giving more metadata about the video frames. Thought it was more useful to get zero-copy with magic, then putting it off until we could do it without magic.
  • KG: just as one example, coded size for 1080p video is often 1088 pixels tall. (rounded to 16x16 blocks)
  • GT: is that stretched, or cropped?
  • KG / KN: cropped.
  • KG: there's also aspect ratio - e.g. something like a square video but it's stretched.
  • GT: bug in WebGL - a 320x240 video in Chrome showing 256x256 in Chrome. Metadata we were treating differently.
  • KG: it's challenging. Still, think displaySize is the right thing to use.
• Increase maxInterStageShaderComponents to 64 #4517
  • KN: this was for old Metal devices we don't support any more.
  • KG: not because we wanted to reserve room?
  • KN: no. Was 64 on Apple3.
  • MW: educational iPad for 2019, still supported in the latest software. So WebKit still supports it. But not for WebGPU. It would be a WebGPU Compat device because of other restrictions.
  • CW / GT: not for Compat. :)
  • KG: recorded, approved. Update Compat to lower this limit separately.

• CW: seems easy except for one tiny name bikeshedding.
• KN: dropped these a year ago - no reason any more to continue excluding them.
• CW: one q, how do we name the unorm8bgra?
• KN: regular one's unorm8x4.
• KG: if other one's x4, should call this one x4.
• CW: unorm8x4-bgra seems clear.
• Agreed all around.

• KG: Reviewed.

• KN: accidentally filed another issue about this. Last time we discussed was last Nov, 2023. Milestone prioritization? An optional feature. If we put it in the spec, don't need to implement immediately. But it's complicated.
• KG: Moz would prefer for M2. But we don't have regular indirect support yet - don't want to build on it before we have impl feedback.
• KN: suspect wgpu already has this.
• KG: not the validation.
• JB: can't enable in Firefox because we need to add that validation pass.
• KN: pretty big thing - our team isn't that excited about implementing this either, at least as much as users want it. No problem with M2.

• KN: came up because we were talking about the C API. Handy - not fundamental to that though. Where we landed with requestAdapterInfo - no reason for it to be async. Just happened because of how we got there.
• KG: I do agree with that. Not that bad to make your own async function with requestAdapterInfo - no hard requirement to make it sync.
• KN I'd still prefer to clean this up in the JS API. If we agree on that I'll probably change the C API to make this synchronous.
• KG: only reason we might not want to do that - think by the time you request an adapter. you get it from a list that already has this info.
• KN: this is once you have the adapter though.
• KG: think this is fine. Deprecate requestAdapterInfo?
• KN: yes - maybe use it later for something that will pop up a permission prompt.
• MW: I'm fine with this proposal.
• KG: let's put up a PR.
• KN: milestone 1?
• KG: yes.

• CW: stance on merging Compat into main spec? Wanted all Compat issues resolved?
  • Don't think we answered this.
  • Let's discuss in next week's meeting.
• Meet 2 weeks from today? Wed Apr 10.
  • Atlantic time.
• Add Agenda Items Here:
  • Add support for 3D compressed textures. #3183
  • Compatibility mode: provoking vertex differs between OpenGL and WebGPU #4489
  • Compat: Disallow textureSampleLevel/textureSampleCompareLevel with texture_depth_2d_array #4519