Chair: CW

Scribe: KR

Location: Google Meet

• Administrivia
• CTS Update
• Seeking approvals
  • Move GPUAdapter isFallbackAdapter attribute to GPUAdapterInfo #5099
  • Make the last 2 arguments to copyBufferToBuffer optional #4807
  • Allow using a texture view for an externalTexture binding #5079
• Discussions
  • Compat: maxStorageBuffersPerShaderStage doesn't need to be lowered #5103
  • Spec requires mappedAtCreation to still work after device is destroyed #5102
  • mapAsync() algorithm's deviceLost variable is uninitialized on validation error #5101
  • mappedAtCreation size alignment is checked after mapping already happened #5105
  • Improve source size calculation used by copyExternalImageToTexture with HTMLImageElement #5097
  • (socialize) Add optional feature "buffer-map-extended-usages" #5108
    • And explainer for the proposal
• Agenda for next meeting

• Apple
  • Mike Wyrzykowski
• Google
  • Corentin Wallez
  • Geoff Lang
  • Kai Ninomiya
  • Ken Russell
  • Loko Kung
  • Stephen White
• Mozilla
  • Jim Blandy
  • Kelsey Gilbert

• Still need to decide on the F2F dates.

• No objection to making the spec change. Chrome will add the new one and add telemetry for usage of the old one (and tell the WG about it) before removing it.
• KG/JB/MW: (thumbs up)

• (no comments)
• all: (thumbs up)

• Resolved: Make it the same as the list of supported canvas context formats

• KN: Now that we have separate limits for vertex/fragment, the combined one doesn't have to take into account the combined ones. Can go back to 8. Pretty simple.
• Agreement all around.

• KN: spec currently lets you destroy the device, then create a new buffer with MappedAtCreation. Weird. On lost devices that haven't been destroyed, you don't know the device is lost, and we don't automatically unmap things either. Destroying the device is more explicit. Think we should throw an exception here, like how we handle out-of-memory.
• KG: to me the device destroy behavior is to replicate device lost. High level goal of device loss is we try to make it so if it happens between two JS calls, it doesn't generate an exception with no chance for you to recover. For device loss, want some sort of limp-along behavior. Would prefer this for device destroy as well. If we want to treat device destruction as more explicit, think we should generate warnings upon weird things since the last device destruction. On the other hand, think things that can happen after destruction wouldn't be that bad. getMappedRange should succeed after device destroy.
• KN: will have to think about it. In our impl we have a one-shot thing, after everything's destroyed, won't be anything else to clean up. As a state machine, it works well.
• MW: after device destruction, thought we can't use any of the buffers again because they're tied to device. What's the use of allowing these operations after GPUDevice.destroy?
• KG: then subsequent calls to getMappedRange will have different behavior if you call device.destroy() or if the device is lost.
• KN: we also have a problem with synthesizing device loss, our device.destroy() doesn't do that well right now.
• KG: Moz thinks it's fine if we do nothing. But probably do want to look at device loss and device destroy again.
• KN: think we shouldn't try to make this more like device loss - it isn't. Should just do something else to synthesize device loss.
• CW: open to a method on the device like "forceLoss()"?
• KG: if we think we should have different behavior for these two things, yes. Not sure that's true. Ideally wouldn't have 2 commands that do the same thing. Shouldn't be spec differences between destroy and loss, IMO.
• KN: loss doesn't unmap buffers; destroy does right now.
• KG: don't think we should end up with 2 functions.
• CW: think destroy(), that it unmaps the buffer, is good because it reclaims memory promptly.
• KR: have a partner that has run into issues with maps not being cleaned up.
• KG: don't want to be in a situation where device.destroy() unmaps buffers and then you can create with mappedAtCreation though.
• KR: understanding that destroy and loss are different, I would err on the side of forbidding mappedAtCreation.
• CW: need to figure out the plan for destroy() vs. forced loss. Lots of tiny unrelated issues. Can you make a proposal? See how things are, see if we want the two functions or not.
• KN: will do.

• KN: spec bug. In logical flow of mapAsync, there's a deviceLost variable, not set in one of the paths. Should decide false vs. true. Specifically, if the device is already lost when mapAsync starts, should you get AbortError or ValidationError? I think AbortError.
• KG: no strong intuition for this.
• Agreed on AbortError.

• KN: validation rule in CreateBuffer, size must be multiple of 4. Don't do it until the device timeline. So we've already mapped at this point.
• CW: 4 options here. 1 is breaking (moving to client side).
• KG: let's just require the alignment.
• Agreed.

• KN: could point to WebGL, doesn't allow scaling during this upload.
• Discussion
• Get back to this later.

• And explainer for the proposal
• Two special cases, contents of the mapping in certain situations, and …
• CW: things we want from this extension? One thing, any GPU-based validation cannot be attacked by someone writing randomly in the mappable buffer still visible in the JavaScript process. From this, can we keep indirect in the list of mappable usages or not? Same thing for index, depending on how robustness works in various impls.
• CW: specific questions? Maybe we can come up with requirements?
• (No questions from the working group)
• CW: things we want from this extension? First, do we want this always, and emulated on discrete GPUs?
• KR: think shouldn't - hard/impossible to get good performance all the time for all applications.
• AB: ARM has strong opinions. Important for the reasons listed. For us, imp't that it works on our GPUs. Can't require host cache and coherent memory. Our best practices are written down, but host memory interface is implemented by the OEM, so you rarely get that. Nice to avoid flushing/invalidation, but it's easy to do in the impl. We aren't exposing persistently mapped buffers. Still have to map/unmap so that's where you flush/invalidate.
• CW: problem with just coherent + non-cached is: we're hoping to triply map buffers. Create shmem in JS process, send to GPU process, use API-specific method to import that memory into GPU address space. VK_external_memory_host (_fd?). Also Metal and D3D12. If we do this, JS has an ArrayBuffer that becomes uncacheable. Seems weird to expose uncacheable memory to JS. [surprising performance properties]
• AB: that's fine. Invalidate/flush on map/unmap's all that's required?
• CW: yes.
• CW: more feedback for Jiawei?
• (None in the meeting)

• Will ask folks in Shanghai if they have enough topics for a Pacific time meeting. So maybe next week or the week after.
• Add optional feature "buffer-map-extended-usages" #5108
• [Immediate Data] Shall we support per-stage immediate data? #5116
• [Immediate Data] Add internal slot immediate data in GPUBindingCommandsMixin #5117
• [Immediate Data] Support SetImmediateData() in RenderBundle #5118
• [Immediate Data] Rename <immediate_data> to <immediate> #5119
• Consider allowing overridden pipeline constants to refer to a non-existent identifier string #5112
• Resurrect clamp-to-border #1305
• Add device.simulateLoss(), and prevent mappedAtCreation on destroyed devices #5115