Chair: CW

Scribe: KN

Location: Google Meet

• Administrivia
• CTS Update
• Add [AllowShared] to setBindGroup #5202
• Auto-enable rg11b10ufloat-renderable with texture-formats-tier1 #5200
• Determine whether we can drop MTLGPUFamilyMac1 support #5187
• Consider lifting size%4 requirement of copyBufferToBuffer and writeBuffer #5203
• GPUExternalTexture.expired is described as immutable but is definitely not #5196
• (stretch) Triage the rest milestone 1 issues
• Agenda for next meeting

• Google
  • Brandon Jones
  • Corentin Wallez
  • Geoff Lang
  • Gregg Tavares
  • Kai Ninomiya
• Microsoft
  • Rafael Cintron
• Mozilla
  • Jim Blandy
  • Teodor Tanasoaia
• Mehmet Oguz Derin

• CW: I'll send another email about scheduling the F2F. Please send your scheduling constraints to me
• JB: Question about whether an invited expect can be a chair
  • CW: Think FD said it's fine

• No specific update.

• This has already been merged.
• KN: FYI, please complain if this is a problem.

• JB: Thumbs up. Like showing the feature is available when its functionality is available.
• (MW approved online)
• Resolved: do this.

• CW: We have some stats from a subset of our Mac population and it doesn't look great. About 8% in MTLGPUFamilyMac1.
• GL: Matched my findings with ANGLE's Metal backend too. There's one MacBook Air which is common in the wild that has a max macOS version of 12. So whenever we drop that. [Chrome supports macOS 11.]
• JB: We support macOS 10.13.
• JB: We don't think that core WebGPU should be adding restrictions that cause us to drop hardware.
• CW: We did raise the minimum required Metal version at some point (to 10.14?)
• JB: Wasn't that before CR?
• CW: Yes. Agree with you that hardware features shouldn't be required (until they're VERY old like in 10 years)
• Resolved: Don't drop support.

• KN: These two entrypoints require the size of the copy to be a multiple of 4. This came from a Metal limitation if we can do it via workaround or by ignoring it (because it just works), it would be very nice for devs.
• KN: Filament reported having this work on Apple Silicon GPUs. Asking Apple to investigate if it is possible. Could do a workaround on some hardware that would require it. The doc says that iOS and tvOS don't have the restriction that would point at Apple GPUs not being expected.
• JB: If the limitation doesn't exist then let's not have it in WebGPU but we don't want to advance the core spec by losing support for hardware. Also don't want to workaround to have a memory cost in the size of the copy. (Though we currently have one for D3D12 texture copies.)
• JB: It's not the only alignment restriction in the spec, why this one and not the others.
• CW: This one creeps up in a lot of random places. It happens to impact the mappedAtCreation buffer size alignment. It has been annoying to people, not the first time it's been an annoyance. Align sizes of ring buffers / staging buffers, have to round up….
• JB: These copies have to be either f16 or texture related?
• KN: Also vertex data. Think that's the most common.
• KN: Why this one: because it is very common for vertex data, and existing engines rely on no alignment because the limitation doesn't exist.
• KN: Believe it is possible to do a workaround without a copy (make a texture view of a buffer). But even with a copy, an extra copy is only needed for the last 1-3 bytes.
• JB: Constant size copy for workaround is fine.
• KN: BTW, D3D12 thing doesn't actually require an extra copy. Just a pain to do without it.
  • CW: We are currently trying to fix a difficult bug that showed up in our D3D12 texture copy splitter.
  • JB: OK taking the hit for now.
  • CW: The code is not too bad if you split 3d copies up into one copy per slice.
• CW: Revisit after Mike finds out if this is a real restriction in Metal?
• KN: Think that's best.

• JB: (summary). Think we just need to change this to a device-timeline property like destroyed states. However, since it is written from the content timeline, not sure if it will actually work to defer that write to the device timeline.
• CW: Device-timeline was was what we intended or at least what we implemented in Chrome. Interop (video-webgpu, webgpu-webgl, etc.) have ways to synchronize with each other. Here, synchronizing an HTMLVideoElement with WebGPU. What we are saying is that the video frame can expire before it gets used on the GPU
• JB: We have a content process that sends IPCs to a GPU process. The interesting interaction is with the compositor. That's where we have coordination of letting WebGPU execution finish before the compositor tries to use the output to put something on the screen. That coordination seems to be pretty ad hoc at the moment.
• JB: Committee has two responsibilities here, make sure the validation is coherent (it is not currently) and to make sure it's sufficient for implementations to do a good job. The spec assumes that resources will be around long enough to be used. Question is what conditions are enough for Firefox to have a clean implementation of this.
• CW: If you look at HTMLVideoElement, the GPUExternalTexture expires "immediately" (at the end of the JS task in which you import it).
• JB: Won't last until end of the frame? Surely it won't expire before the rAF callback ends?
• KN: If you import during the rAF callback, yes, it will last until the end. Just not if you do it in a different task before the rAF callback.
• JB: OK. Can't expire in the middle of a microtask.
• KN: Correct, but BTW, video on the web is completely asynchronous, does whatever it wants whenever it wants.
• JB/KN (clarifying): external textures won't change state during a task, can be used until the end of the task they're imported in (including microtasks attached to the same task).
• KN: makes sense to move to device timeline, but agree not sure if it works. Looking now at instances of expired though, it does seem like it's probably fine. The usages in the spec are very simple.
• KN: ISTR that we have a content-timeline state for this. Not sure why.
• CW: We do have something… [a copy of the device timeline state, early validation, …]. Signalling between VideoFrame/HTMLVideoElement an GPUExternalTexture.
• JB: Will write a PR and come back with more details on Firefox implementation.

• Next week's meeting is cancelled.