Skip to content

GPU Web 2023 06 28

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

GPU Web 2023-06-28 (Atlantic-timed)

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

Chair: Corentin

Scribe: Ken

Location: Google Meet

Tentative agenda

  • Administrivia
    • Color on the Web CG request for comment on this HDR explainer.
    • Ping meeting 9AM PST July 6th?
    • Discussion about webgpu github org.
  • CTS Update
  • “Tacit Resolution” Queue
    • Allow SharedArrayBuffer in writeBuffer/writeTexture with AllowSharedBufferSource #4188
  • Process for landing milestone 2 changes
  • Space efficient wide color support #4108
  • 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
  • Agenda for next meeting

Attendance

  • Apple
    • Mike Wyrzykowski
    • Myles C. Maxfield
  • Google
    • Brandon Jones
    • Corentin Wallez
    • Gregg Tavares
    • Kai Ninomiya
    • Ken Russell
    • Loko Kung
    • Shannon Woods
  • Mozilla
    • Jim Blandy
    • Kelsey Gilbert
  • Nvidia
    • Anders Leino

Administrivia

  • Color on the Web CG request for comment on this HDR explainer.
    • TL;DR: they add 2 predefined colorspaces. rec2100 pq and hlg.
    • Creating 2D canvas context, can ask for storage to be fp16.
    • Then you can get HDR on the screen!
    • For WebGPU, since we use PredefinedColorSpace enum in the spec, and since canvases can be configured with RGBA16F, WebGPU already supports this proposal with no needed spec changes.
    • KN: need to talk with ccameron about this. Didn't align with what he wanted, need to understand situation. But overall, probably good.
    • CW: overall, if someone has a concern, can file a bug against ColorWeb CG. Can still discuss in this meeting. Come to consensus on resolution.
    • MM: procedurally what will happen here? Joint meeting, or post on github issue?
    • CW: probably Github issue unless conversations get complicated.
    • MM: we do have opinions, discussing internally.
  • PING meeting 9AM PST July 6th?
    • #3101 Fingerprinting surface issue.
    • PING allocated 20 mins if we want to talk with them.
    • KG: we do.
    • CW: people interested, is this day/time doable?
    • KG: I might copy this meeting and all the people on it into that timeslot, mark it optional.
    • CW: works. Think only 30 min at that time.
    • MM: we don't use Google Calendar. Email to internal list would be helpful.
    • CW: will confirm our attendance and send followup email if we're confirmed.
  • Discussion about webgpu github org.
    • CW: proposal: say it's unofficial, the group can come and say we'd like you to this and people would do it because they're nice community members
    • People who are in the CG and some who aren't
    • Idea: Jasper St. Pierre could be one non-CG member who would be a maintainer of the org
    • Some of us as well; mrdoob if they like.
    • Thoughts?
    • KG: still unclear on a bunch of things regarding that
    • MM: me too
    • KG: in particular, appointment of moderators, governance - we probably have opinions on this
    • MM: wish we could sidestep this. Say community stuff goes on MDN
    • CW: this is about code, not docs.
    • KR: example: webgpu sorting algorithm written during chrome’s exploration sprint
    • KG: want clear picture of what you want out of it
    • CW: Wasm github org. Happens to be the standardization thing - not aiming for that - but they have test suites, optimizer, compiler toolchain, runtimes, libraries, etc.
    • KG: how does stuff get added to it?
    • CW: don't know
    • KG: that's important. If it's going to be ours, we have to care about governance. If not, we don't care.
    • KG: if this is Google's…
    • CW: you're an admin right now. Owned by whoever is an admin on Github.
    • KG: existential problems - "premier" ecosystem website happens with someone abrasive/unpleasant in charge. Reflects badly on that entire ecosystem. Not having any centralized place - not having that is better than having that.
    • BJ: you run the risk of having a centralized place with an abrasive person in charge regardless. If we take the stance - we won't be the ones who own that - you'll probably get one that develops anyway. It's the nature of the web. Then we have no say who ended up in charge of it. It's just whoever moved first. Think it's better for us to have some say on it.
    • KG: sounds fine. Then we need to have governance oversight, and vetoes on it. That's all I'm asking. Wouldn't love it if someone could send an email to a random maintainer and get something merged. Want the bar to be a little higher.
    • JB: what if we said, the only power this committee has is to appoint people in charge of it? Then we never discuss anything about the site in this meeting? Then can replace people if there's someone abrasive. Could do this right now.
    • KR: sounds good. Can we do that?
    • MM: bringing up couple tiny arguments that might help the discussion. 1) more low-level a library is, the more it needs this kind of thing. WebGPU's a low-level library. 2) another example in addition to Wasm: ICU/Unicode. Unicode makes the spec, ICU's an impl. Difficult to use Unicode without ICU. Collection of APIs / libraries. Long time, wasn't associated with Unicode. Eventually, Unicode said this division was artificial, brought it into Unicode Github workspace.
    • CW: you OK with Jim's proposal?
    • MM: abstain.
    • KR: how about we go with Jim's proposal?
    • JB: thumbs up. Can I be added to admins?
    • CW: of course.
  • MM: idea for tiny little library. Got feedback from few authors - how you populate ArrayBuffers to send to shader sucks now. Better if there's info about layout of structs so you aren't just putting bytes in an ArrayBuffer. Typed, compositional. Standalone library.
    • CW: exactly what we're thinking about, yes.
    • Gregg has written one of these too.
      • MM: SWEET! That means i don’t have to write one too

CTS Update

  • KN (pretyped):
    • I’m still working slowly on 5-second chunking for WPT, talked with Erich to make sure we won’t break Firefox’s import, have some work to do.
    • Our team has started putting in targeted skips for a proposed “Compat” mode of WebGPU. This shouldn’t affect how anything runs unless you turn it on explicitly.
      • CW: to be clear, we want to bring Compat to the CG for discussion once we're done with V1 stuff.
    • Also: WGSL floating point and f16 stuff, uniformity analysis, createPipelineAsync with device destruction

“Tacit Resolution” Queue

  • Allow SharedArrayBuffer in writeBuffer/writeTexture with AllowSharedBufferSource #4188

Process for landing milestone 2 changes

  • KN (pretyped): I think WGSL discussed this, what did they decide on?
  • KG: I should write something down.
  • KN: was a conclusion reached in WGSL group, or is a proposal needed?
  • KG: think we have consensus, but people don't agree on the names for things. Don't want to say we have consensus until we do.

Space efficient wide color support #4108

  • KN (pretyped): Proposal is to just add rgb10a2unorm to the list of allowed canvas formats.
    • Still wondering what these XR formats are actually used for in DXGI
  • MM: talked about this a few weeks ago. Changes I'm proposing are small. Larger for canvas in general, but not this group.
  • KG: what's your proposal to Canvas?
  • MM: backing store.
  • KG: already exists.
  • KN: canvas doesn't control our backing store - we control ours.
  • MM: we want alignment with all the APIs that can draw into canvas.
  • CW: 2D canvas can specify backing store?
  • MM: sort of. Don't have to discuss, not part of our group.
  • KG: problem, there's a split with canvas stuff. Folks who work on canvas element don't know the constraints for WebGL. Don't want them to come up with a solution that doesn't work for us.
  • KN: that group works mostly on 2d canvas. if we want something concrete from canvas spec we should come up with a proposal here.
  • CW: here, seems we only want rgb10a2unorm backing.
  • MM: want (1) when we render stuff, please interpret the rendering outputs as being in one color space or another. (2) way for the numbers we render to have more than 256 representable values per channel.
  • KG: (1) is solved in my head. Have it in WebGL, think solved in Canvas 2D. (WebGPU too)
  • CW: just need to allow rgb10a2unorm in canvas configuration.
  • MM: yes.
  • KN: don't think there's anything to talk with the canvas team about. Their spec doesn't need to change. Just accept the fact, we hand it an image with some numbers, they don't know it's discretized in a particular way. Canvas spec should handle that. Not sure there's anything for them to do. We already have float16 in our spec though. Think it's entirely in our court. When it comes to impls, figure it out with our canvas teams.
  • MM: would like to request that unless anyone has other proposals to make in this topic, let's table it.
  • CW: can we agree to just add rgb10a2unorm to our canvas formats?
  • KG: format for GPU canvas configuration?
  • CW: yes.
  • Consensus. Add to the spec.
  • KG: most likely thing to have trouble with it is probably Android. We'll find out.
  • CW: the browser compositor handles it.
  • Discussion about bgr10. Doesn't exist in WebGPU yet.
  • KG: if there's a fast path, bgr10 exclusive - we want to be able to hit it as an implementation. But we don't know about it so would like to.
  • MM: can give a longer answer. Discuss in an issue.

Image uploading is insufficiently expressive to be optimized #4185

  • KN: what do you think KG? You thumbs-up'd [the issue summary].
  • KG: liked the statement of the problem. Reminded - we know ImageBitmap's not efficient for this. Main complaint: assertion that ImageBitmap's the way you want to upload in WebGPU. We feel that's not true. What'd need to change - either a better way, or - when we talk to external people, don't say that ImageBitmaps are the thing you want in all browsers.
  • BJ: at the moment, everything goes through either ImageBitmap, canvas or video. Originally - saying don't go through ImageBitmap - it's more Fetch -> Blob -> ImageBitmap not being optimized for Firefox. In all cases, going through ImageBitmap. Are you looking for a way to sidestep ImageBitmap entirely? Or more consistent way to get into ImageBitmap?
  • KG: (1) developer engagement. When we respond to issues in chat channel, don't say, please always use ImageBitmap on all browsers. That's not true.
  • BJ: backing up - there isn't a different alternative except for blitting into canvas.
  • KG: saying - if you can avoid IB, please do. Firefox prefers it. There are some cases where you can't avoid it. Has been attitude in general that you should think about ImageBitmaps as the way to use images in general.
  • GT: what's the alternative?
  • KG: in WebGL you can upload from HTMLImageElement. Asking for people to talk more carefully.
  • CW: should we write a best practice doc on MDN describing these tradeoffs?
  • GT: trying to understand, what's the alternative on FF being discussed.
  • KN: can explain all the alternatives.
  • KG: what can we do better here - more productive.
  • Discussion about the origin of the question and what was discussed on the Matrix chat.
  • KN: is there a reason we shouldn't add another path?
  • KG: relative priorities - think valuable to have faster upload. But for images - not very valuable, probably. Relatively cold code to upload images. Extra copy isn't the end of the world. Thing I was concerned about - don't tell people to use ImageBitmaps all the time for loading images on the web platform.
  • KN: agree. I think we should write an MDN doc for this, and we shouldn't push ImageBitmap as the end-all for handling images. On the Matrix chat - my advice was meant to be just, put the Blob into the ImageBitmap instead of HTMLImageElement -> ImageBitmap. But I see it could have been interpreted as doing this all the time. Think we should write the MDN doc.
  • KG: +1.
  • CW: also, add HTMLImageElement for source to copyExternalImageToTexture.
  • KG: sure. Reason we didn't do that is we didn't want to write the spec for it.
  • BJ: also, want to encourage people to use compressed textures. Think we should emphasize that more.
  • KG: different concerns about that.
  • KN: can put it in MDN article.
  • MM: if we add HTMLImageElement then we should add everything that texImage2D in WebGL accepts.
  • Discussion of writeTexture vs. copyExternalImageToTexture.
  • MM: seems to me that if sources will be HTMLImageElement, videoframe - one should be a dictionary that has an ArrayBuffer, layout, etc.
  • KN: only things missing are HTMLImageElement and ImageData. ImageData you can handle with writeTexture, but OK with adding these as copyExternalImageToTexture inputs.
  • CW: waiting for proposals.
  • GT: comparing to WebGL, the reason we have ImageBitmap is that we wanted to be able to ignore colorspace, flipping images, etc.
  • KN: we have these on copyExternalImageToTexture.

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

  • CW:
    • triply-mapped vs. not
    • UMA vs. discrete
    • Read vs. write
    • GPU process vs. not (but nowadays everyone has a GPU process, so one less dimension)
  • Depending on semantics of zeroing / getting data back from GPU, what happens?
  • If triply mapped, and on mapWrite you zero out data - inefficient. You don't need to do that zeroing.
  • Not zeroing memory - then if not triply mapped, need to copy data from GPU process back to shmem. Extra copy.
  • No obviously optimal path.
  • Similar question about readable buffers and if you write into the buffer.
  • So, given all that, I don't know how we make an API that's efficient everywhere, and has portable semantics. Portability seems super important.
  • MM: thank you, that was exactly what I asked for.
  • CW: we're super interested in this, would like to design something that works well. Maybe one bit, are you UMA or not? Or browser says this would be most efficient, but the other one works too.
  • MM: agree. Think we haven't exhausted the search space. I'll talk with the team about it and see if we can come up with anything interesting.
  • KG: maybe we can contribute toy ideas we discussed at Mozilla. Copy you have to do on UMA vs. non-UMA. Didn't think about zeroing. Thinking about - how do you have something that functions on both, maybe worse on one of them, but can be good on the other? Perf characteristics not guaranteed. May need to know if you're UMA or not. Think there's room for an API that can do a pretty good job. Mostly do the reasonable thing. Do the copies when you need to, but elide them on UMA.
    • State transition idea, transition usages for buffer. Non-UMA archs, might incur copy to GPU, enqueue those.
    • Other idea, Jim's: what if you had destructive copy / move semantic. Two names for buffers? Same memory, really? When you copy / move data between them, we say - it's that buffer now, you can use it? And on non-UMA we'd do the copy.
  • MM: both interesting ideas. Our hesitance about UMA-specific code path isn't about fingerprinting. Instead, mostly about - don't want people who write code for discrete GPUs to have bad perf on UMA GPUs
  • CW: great that everyone wants to find a solution, and great to see these new ideas. We'll figure something out.

Agenda for next meeting

  • APAC timed. Will ask Intel for agenda items.
  • KN: holiday week during US.
  • MM: I vote to cancel.
  • KG: think the one following that should be APAC timed.
Clone this wiki locally