>>>>> gd2md-html alert: ERRORs: 0; WARNINGs: 1; ALERTS: 0.

• See top comment block for details on ERRORs and WARNINGs.
• In the converted Markdown or HTML, search for inline alerts that start with >>>>> gd2md-html alert: for specific instances that need correction.

Links to alert messages:

>>>>> PLEASE check and correct alert issues and delete this message and the inline alerts.

Chair: JG

Scribe: KN, JG

Location: Google Meet

• CTS updates
• Milestone triage (timebox 15m) #2073 (currently triaging V1 issues, start at #1358)
• Adding invertY and preMultiplyAlpha options to copyExternalImageToTexture #2324
• Support webgpu context canvas for copyExternalImageToTexture #2350
• Extend lifetime of GPUExternalTexture imported from video element #2302
• importExternalTexture in WebCodecs spec w3c/webcodecs#412
• (quick?) Rename fillBuffer to clearBuffer #2368 (needs Apple approval)
• texture_2d_depth for loading depth values might be unnecessary? #2094
• (stretch) GPUAdapter.name considered harmful #2191
• (stretch) Expose blocking operations on workers #2217
• Agenda for next meeting

• Apple
  • Myles C. Maxfield
• Google
  • Brandon Jones
  • Gregg Tavares
  • Kai Ninomiya
• Intel
  • Hao Li
  • Jiajia Qin
  • Jiawei Shao
  • Shaobo Yan
  • Yang Gu
  • Yunchao He
  • Zhaoming Jiang
• Microsoft
  • Rafael Cintron
• Mozilla
  • Jeff Gilbert
• Unity
  • Brendan Duncan

• KN: Please contribute!

• https://github.com/gpuweb/gpuweb/issues/1371
  • Still v1
• https://github.com/gpuweb/gpuweb/issues/1380
  • JG: I think not necessary for v1
  • MM: +1
  • KN: I think this will be done over in webcodecs, so it’s on track for solving by v1
  • JG: It might happen by v1, but I think the deadline doesn’t need to be v1, thus post-v1 here
• https://github.com/gpuweb/gpuweb/issues/1400
  • KN: Not important, but small and nice, so let’s just v1
  • MM +1
• https://github.com/gpuweb/gpuweb/issues/1422
  • Already needs-spec
• https://github.com/gpuweb/gpuweb/issues/1482
  • v1
• Next time start at 1483

• SY: Would like to better understand the issues Babylon is encountering.
• KN: Babylon finding it difficult to both (a) maintain compatibility with their WebGL backend and (b) not change the behavior of their WebGL backend.
• MM: Seems generally useful. May have a performance penalty, but not worse than the user having to flip the image themselves with a render pass. Weakly inclined to add this.
• JG: Warn if it does something slower than the fastest possible thing. Done this in Gecko for WebGL and has been successful. Give information that it’s slow and why.
• JG/SY: flipY:false may be the slow path sometimes. Gives control to avoid slowness (KN: Like with webgl source. JG: possibly with video sources etc)
• SY: Agree with adding flipY.
• Resolved: Add Y orientation control

• SY: JQ found this wasn’t allowed. In TF.js
• KN: After discussing this I think we should allow this.
• JG: Implementer-to-implementer, this doesn’t have to be fast. So the implementation doesn’t necessarily have to be complex.
• MM: JQ asked to allow webgpu canvas, KN’s argument says all canvases should work.
• KN: Less concerned about the others: “none”, “placeholder”, “bitmaprenderer”
• JG: Can you toDataURL from a “placeholder” (transferred to offscreen) canvas? I don’t think it’s well defined. If yes, I think it should work here. That’s a good litmus test for what we should support.
• ...
• MM/JG: Use the same incantation as the HTML spec for whether you can do this.
• Resolved.

• MM: So it sounds like if a new video frame is decoded, the old frame expires. Does that mean it only effectively works with requestVideoFrameCallback?
• KN: You can still ask for the external texture again/repeatedly. rVFC just lets you know when the frame updates, and thus whether you need to update your ExternalTexture.
• MM: This also means they need to regenerate the bindgroups? (yes)
• ai: JG to review offline

• KN: Have proposed a draft change to WebCodecs to host the spec for interaction between WebCodecs and importExternalTexture.
• KN: Have chatted with WebCodecs folks and they are happy to host this. It’s small and well-contained. We would need to revisit if we want to expand it - in particular if we have a per-plane importing API which could get much more complicated.
• (General neutrality/agreement with the approach)
• MM: Removing this problem from our community group makes it easier for us!
• ai: KN to un-mark the WebCodecs PR as draft and take care of getting it landed

• …
• MM: Revisiting the previous decision?
• KN: Revisiting because DM was out. DM doesn’t think we should create totally new functionality here (rather than just exposing the buffer-clearing we already have), because there is no easy implementation on D3D12.
• MM: Thought the implementation strategy on D3D12 was to use storage (clear UAV).
• KN: Ah yes. That’s substantially different from clearBuffer though. Requires different validation. IMO if the validation is different the function should be different.
• JG: Counterproposal would be to just have fillBuffer special case that it only requires STORAGE usage if byte is not 0.
• JG: …
• MM: Think fillBuffer is useful and should be present in MVP. Agree with KN that, if we have different requirements for fillBuffer (STORAGE usage), it should be a different function.
• MM: Would like to avoid one of these being in V1 and the other not.
• KN: Not convinced that filling bytes is actually sufficiently useful to justify the implementation cost. Can imagine it being useful to fill to float 1.0 for example. But bytes seem extremely limiting.
• JG: What are the backend limitations?
• MM: D3D can only fill STORAGE buffers. Metal can only fill bytes.
• ...
• MM: Willing to polyfill a fill-with-four-bytes function in Metal.
• (group interested, would like proposal and to discuss when DM is present)
• Resolution: approved this change
• ai: MM to file a new issue proposing both fillBuffer8 and fillBuffer32.