Skip to content

GPU Web 2023 07 12

Jump to bottom
Corentin Wallez edited this page Jul 13, 2023 · 1 revision

GPU Web 2023-07-12/13 (Pacific time)

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

Chair: KG

Scribe:

Location: Google Meet

Tentative agenda

  • Administrivia
  • CTS Update
  • “Tacit Resolution” Queue
  • Image uploading is insufficiently expressive to be optimized #4185
  • Cannot upload/download to UMA storage buffer without an unnecessary copy and unnecessary memory use #2388
    • MM: Nothing to discuss here yet :)
  • <more agenda items from APAC participants?>
  • Agenda for next meeting

Attendance

  • Apple
    • Dan Glastonbury
    • Mike Wyrzykowski
    • Myles C. Maxfield
  • Google
    • Brandon Jones
    • Gregg Tavares
    • Kai Ninomiya
    • Ken Russell
  • Intel
    • Hao Li
    • Jiawei Shao
    • Zhaoming Jiang
  • Microsoft
    • Rafael Cintron
  • Mozilla
    • Jim Blandy
    • Kelsey Gilbert

Administrivia

  • PING meeting update
    • KG: Met with PING.
  • Had been hoping for dispute arbitration, but didn't work out that way
  • No tangible result yet
  • Recommendation: try harder to write stuff in the spec which makes the recommendations tangible
  • Have suggested that
  • KR: One PING member from Brave was adamant about wanting to reduce fingerprinting more. Someone (Jepointed me to a post from Brave about “farbling” which they use in getBufferSubData etc.
  • Would like to schedule more dedicated time with them, probably at our meeting. Only had 20 min scheduled at that meeting and it took 40 min.
  • Folks from this group expressed that we can’t have a permission prompt in general, and about the protections we have in place
  • Request to add permission for WebGPU. WebGPU reps at the meeting said that's really undesirable
  • PING said it would be better if we spec'd there could be a permission, even if UAs don't actually raise it
    • We discussed this earlier in the "additional info" in getAdapterInfo
    • If this would satisfy the PING, we could add that to the spec, though
    • KN: We didn't want to raise this prompt due to compatibility. If folks who want to raise that prompt are OK with the compatibility issue, we can add it to the spec
  • MM: farbling - something we intend to do in WebKit, spec doesn't forbid it. Maybe spec could say it's OK to do it. But spec shouldn't say that UAs must do farbling. Complex fidelity/privacy tradeoff, different browsers are at different places on the spectrum.
    • If the spec says it normally, how does a browser know when they are complaint? If it can’t be measured or tested, how can it be normative in a spec?
    • Spec can't really say anything binding.
    • KG: surprised WebKit wants to do farbling - I've pushed back against this internally. Math results matter. Given a buffer of data, you don't know what it is, how can you "farble" it reliably?
    • KR: I share the same concern.
  • KG: if we wanted to spec a potential permission prompt, even if 90% of UAs don't implement it, would that satisfy the PING? Open question.
    • MM: is there any reason to not spec that?
    • KG: if people think it'll help, it can go in - but only useful if it's adding useful information.
    • MM: the term "may" in the specs is intended for this situation. If Brave wants to do it, "may" sounds like the correct term.
    • KG: want to have that direct feedback to the CG before moving in that direction.
  • Can go back to them with this feedback, invite them to this group.
  • MM: is purpose of this topic to address technical privacy concerns, or figure out next steps? Ken proposed some next steps, they sound fine.

CTS Update

  • KN: adding some places in the CTS to handle potential "compatibility mode". Work ongoing, Gregg's focusing on it.
  • WGSL team at Google cranking out lots of tests. Coverage is improving.
  • WPT chunking: no progress.
  • KG / JB: no major news.

“Tacit Resolution” Queue

  • Add rgb10a2uint texture format #3841
    • Do we add this, or being held off as a new feature until a later version of the spec?
    • Is it milestone-2, or polish?
    • KG: I don't mind adding this
    • JB: no objections.
    • MM: we're still implementing, so this can slide in, regardless of the milestone labeling. Can't imagine our first release wouldn't contain this.
    • KG: let's take it then.

Image uploading is insufficiently expressive to be optimized #4185

  • KN: there's ImageDecoder in WebCodecs. AFAIK, can stream downloading with decoding. (so can image elements, if they're onscreen). No way to do this with WebGL. You finish download, then wait for decode. Decode might have started earlier.
  • KN: are people interested in this? Pipelined download+decode, get result into WebGPU in some way?
  • MM: think 2D canvas should do this first.
  • KN: reasonable idea.
  • MM: follow best practices that they trailblaze.
  • KG: sort of disagree with the general direction.
  • BJ: moving this decoding step - directly into the texture buffer? Still having discrete decoding step, then single block upload?
  • KN: potentially yes. I don't have a concrete proposal but think we should consider it.
  • BJ: struggling to see how that'd work.
  • MM: that's why I suggested 2D canvas first, let them figure that out.
  • KN: 2D canvas only has drawImage.
  • KG: it has patterns.
  • GT: how does that change things?
  • KG: patterns behave like resources. Like the idea, maybe some confusion about what it means. If you want to tell browser, "it's coming from here, my goal's to get it here", do that efficiently. Maybe not decode directly into the texture. Maybe blocking mechanism? Help the browser know where it's going.
  • KN: that's the idea. Most independent single idea: you have a URL, want to get it to a GPUTexture that has that image in it. Widest net to cast. Gives browser lot of info to pipeline things.
  • MM: another thing it could do - automatic texture compression. Not sure how website'd indicate what it wants, but automatic compression could be useful.
  • KR: sort of think we already have the needed primitives - Fetch, Basis Universal toolchain, … - and that maybe this isn't one of the problems we should be solving right now.
  • BJ: sort of agree with Ken. Getting images into textures and … loading assets … I look at glTF loaders a lot, and a lot of the time goes into image decoding. Don't think we should dismiss it as "we already have the tools", but think that "createImageFromURL" is the wrong level of abstraction.
  • MM: similar to what I was going to say. Counterargument of images->textures not being a bottleneck - it's more common for apps to put images into textures than to put videos into textures. For all the content in the real world, more time's spent in image->texture path. Would like to see this working in e.g. 2D canvas, though, but keep an open mind and not dismiss it.
  • KG: caution with 2D canvas, they have different performance constraints. Maybe not good idea to dismiss this.
  • MM: "not right now"?
  • KN: ok, stopgap then? Support HTMLImageElement uploads?
  • KG: tricky part's done already. Need to do it for 2D canvas/WebGL. Sort of a wart that you can't upload images.
  • Discussion.
  • KR: I see the premultipliedAlpha knob's there for potential HTMLImageElement uploads. Caution, the first thing applications will run into is the synchronous re-decode of those elements if you specify premultipliedAlpha:false.
  • KG: understood. Performance warning?
  • BJ: feels it would have to be an async API
  • KN: think it's complex to design this as async API, think we should do the same thing 2D canvas and WebGL do: blocking decode. Not really adding one.
  • KG: it's the omission of "image" vs. "video" that feels like a wart.
  • KG: if someone can put together a PR, we can look.
  • KN: there's a PR for both HTMLImageElement and ImageData. Same union as for the other APIs.
  • MM: ship it. :)
  • GT: Q about ImageData. Used to be w/h/ArrayBuffer. Shouldn't I be able to supply that from JS?
  • KN: can do that with writeTexture. Also can have colorspace, premultiplication. Always has alpha.
  • GT: it's 100% transparent - other objects are opaque.
  • KN: also ImageData constructor which takes the array, just wraps it.
  • KN: should we do it?
  • KG: I'm OK with ImageData being there.
  • MM: ImageData sounds great, do it.

Cannot upload/download to UMA storage buffer without an unnecessary copy and unnecessary memory use #2388

  • MM: Nothing to discuss here yet :)
  • MM: was on the agenda to gather requirements, that's now done. Working on a proposal.

<more agenda items from APAC participants?>

  • Nothing from Intel :)

Agenda for next meeting

  • KG: if we meet in 1 week, likely not a lot to talk about, unless UMA investigation proceeds
  • MM: unlikely
  • KG: plan to meet again in 2 weeks then. Atlantic-timed meeting.
  • Discussion about Descriptor heap management bug in Dawn's D3D12 backend:
Clone this wiki locally