Skip to content

Minutes 2021 12 01

Corentin Wallez edited this page Dec 7, 2021 · 1 revision

>>>>> 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.

GPU Web 2021-12-01

Chair: JG

Scribe: KN, JG

Location: Google Meet

Tentative agenda

  • 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) 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

CTS updates

  • KN: Please contribute!

Milestone triage (timebox 15m) #2073 (currently triaging V1 issues, start at #1358)

Adding invertY and premultiplyAlpha options to copyExternalImageToTexture #2324

  • 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

Support webgpu context canvas for copyExternalImageToTexture #2350

  • 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.

Extend lifetime of GPUExternalTexture imported from video element #2302

  • 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

importExternalTexture in WebCodecs spec w3c/webcodecs#412

  • 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

Rename fillBuffer to clearBuffer #2368

  • 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.

texture_2d_depth for loading depth values might be unnecessary? #2094

(stretch) considered harmful #2191

(stretch) Expose blocking operations on workers #2217

Agenda for next meeting

Clone this wiki locally