Chair: CW

Scribe: Ken / Corentin / others

Location: Google Meet

• Administrivia
• CTS Update
• “Tacit Resolution” Queue
• Any new feedback on GPUAdapterInfo?
• GPUExternalTexture active_imports only works if there are RAFs #2785
• Specify that texture_external sampling functions clamp coords to [0, 1] #2766
• All the canvas issues!
  • Handling out-of-memory when resizing canvas backing store #2520
  • rgba8unorm canvas textures and IOSurface #2535
  • WebGPURenderingContext should support preserveDrawingBuffer: true #2743
    • related: Does compositingAlphaMode affect using the canvas as an image source? #1847 (comment)
  • Does compositingAlphaMode affect using the canvas as an image source? #1847
    • Tentatively struck until after we’ve resolved #2743
  • Rely on canvas size instead of allowing size to be configured #2416. Revived in #2826 Remove GPUCanvasConfiguration.size
• Agenda for next meeting

• Apple
  • Myles C. Maxfield
• Google
  • Austin Eng
  • Ben Clayton
  • Brandon Jones
  • Corentin Wallez
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
  • Stephen White
• Microsoft
  • Jesse Natalie
  • Rafael Cintron
• Mozilla
  • Kelsey Gilbert
• Unity
  • Brendan Duncan
• Andrew Varga
• Mehmet Oguz Derin
• Michael Shannon

• CW: Tag feedback read but still not posted
• MOD: I18n posted all the issues, their tracker issue is marked as complete.

• Tons of available tasks, both API and WGSL: https://github.com/orgs/gpuweb/projects/3
• Contributions open; please read: https://github.com/gpuweb/cts/tree/main/docs/intro and assign yourself a task!

• Change GPUError to a base class instead of a union #2853
  • KN: feedback was useful. New proposal by Brandon and me.
  • Most cases can ignore the type hierarchy.
  • Common field: message on error.
  • Haven't asked Jukka about his use case, but confident this'll function for him.
  • KG: SGTM
  • CW: great. Since this is tacit resolution, if any concerns, please comment by end of week.
  • KN: otherwise, will land early next week.
• buffer/device.destroy() unmaps buffer on current thread #2837
  • KN: aspirationally tacit resolution. Don't know whether people will want to tacitly resolve on it. Have talked about it for a while.
  • KN: to free up resources as well as possible, would like to be able to unmap buffers when buffer or device is destroyed.
  • Not necessary - maps can outlive buffers, etc. E.g. in multithreading, unmapping on one thread can't unmap an ArrayBuffer on another thread.
    • We don't define multithreading yet.
  • See PR for discussion.
  • KG: is "thread" the correct term for worker, etc.?
  • KN: think it's "agent" though that's more confusing.
  • BJ: spec'd term is "agent" - but yes, think would be confusing to use that everywhere.
  • MM:
  • KN: basically trying to avoid painting ourselves into a corner when we add multithreading support.
  • KG: easier consensus - destroy() should unmap the buffer - instead of introducing multithreading here.
  • CW: we just need to think about multithreading to avoid future problems.
  • KG: it's probably fine. Not as worried about multithreading because we don't know how it'll work.
  • MM: that's my concern too.
  • KG: again it's probably correct. Destroy() should unmap the buffer
  • KN: we don't have to write this into the spec now. Can leave an issue open on Github or have a hidden comment in the source. I'm fine with that - can just change this to address the language. Destroy on device or buffer -> maps buffer.
  • KG: timeframe for tackling multithreading? Soon after V1?
  • MM: should be soon after V1 - one of most requested features.
  • CW: Kai, please note that in the issue.
• Raise maxComputeWorkgroupStorageSize from 16352 to 16384 #2834
  • MM: Seems fine
• Validate canvas configuration in configure() #2821
  • KN: right now canvas config's implicitly validated during createTexture(). This adds add'l early validation when you configure the context.
• Clarify how to interpret GPURenderPassColorAttachment/clearValue #2795
  • BJ: Didn't have spec explaining how the double clearValues in the spec get converted to texture clear value. There's an intuitive idea of how it happens but nice to spec it.
  • BJ: one thing Kai and I discussed - difficult to know how to strictly define how all backends will do translation here. But can define how doubles are converted into appropriate type for the texture. That's what this focuses on.
  • KN: discussed this a while ago. Decided we'd take IDL-defined conversions and extend them to conversions into texture formats. This doesn't do that. IDL's very strict. In practice, not sure we have much control over the value put into the texture - esp on D3D where we have to emulate some clears with draws. Different than what we previously agreed on. You get the same value as if you wrote out to the texture from a shader. So we don't have to define 2 sets of conversion rules.

• BJ: just popping this to the top of everyone's stack. Significant feature, has been sitting for a while. Some new verbiage. Capturing the same information as previously discussed.
• BJ: looking for feedback from Apple now esp. But feedback from anyone in the group is appreciated. We have sent in the PING review request. Will be an area of intense interest for them. The easier we can make their review, the better. Would like to merge this into the spec.
• MM: no update yet. Will make it a priority.

• KN: Reporting back from talking to Domenic.
• KN: some considerations I wasn't aware of - but they don't change my previous conclusion, which is that the place where we have this currently defined is fine. Don't think it's ever throttled. Domenic says the HTML processing model always runs, is never paused. Steps in it get skipped if nothing to do.
• KN: opened a draft PR linked there - would move expiry step slightly earlier, before event handlers instead of between. Pretty minor.
• KN: still pretty sure we're fine.
• KG: moving it earlier sounds fine. Would like to not have to know the order of the callbacks.
• KN: my feeling too.

• Agenda(KN): We said we’d discuss more offline but haven’t.
• CW: let's work on resolving offline.

• Summary(KN): annevk thinks having our own sizing mechanism (having 3 size states) is too incongruous with the way other canvases work and are specced. This proposal removes size from configure(), just uses the canvas size instead.
• BJ: has been lot of discussion about this. Anne was pretty passionate about not introducing yet another way to resize the canvas's contents. While maybe not the preferred route for Kai and I, helps it align with other web specs. Rely on width/height attributes of canvas, like WebGL does. Use these for getCurrentTexture().
• BJ: one nice side effect: you can call configure() at the beginning of canvas context lifetime. Resizing does its own thing. Happens more naturally as you change canvas size. Don't need to call configure() all the time. Benefit to users - not sure. Have to resize depth/stencil textures manually. Not so awkward that we should keep fighting against this.
• MM: if these two fields are distinct, when one field changes and the other doesn't - canvas context stays configured with the old size? E.g. you're rendering along, and then something changes the width attribute of the canvas.
• KN: it deletes the current texture. Texture you're holding onto will be destroyed and not presented. getCurrentTexture() will give you a texture at the new size. Matches behavior in 2D canvas (which additionally wipes the context state) and WebGL.
• MM: canvas context does have a state. Did you consider having this put the canvas back in a nonconfigured state, so authors are more likely to respond to it?
• KN: sort of considered that. Canvas's don't change size unless program changes the size of the canvas, so not concerned about one part of program having to respond to resize request from another part.
• KG: what about too-large canvas sizes and out-of-memory?
• KN: they'll fail validation in getCurrentTexture. You won't get it synchronously, but can see it's too big by comparing against device limits.
• CW: out-of-memory - another agenda item about that.
• KG: sounds reasonable. Wish there was a better answer.
• KG: one case where width/height can change without programmatic resize is if you set the view to a percentage of the page, and then the user resizes the window.
• KN: pretty sure width/height can only be integers.
• MM: you're thinking CSS width/height, distinct from canvas width/height.

• Agenda(KN): pop stack back to IOSurface problem. #2535 (comment)
• KN: got sidetracked on framebuffer-only issue. Came to resolution on that for now. Let's get back to original question. Summary of options.
  1. Don't make spec change. Penalty if not using preferred format. There are workarounds.
  2. Hide it, and get rid of penalty by giving bgra textures when asking for rgba. Breaks compat with render pipelines.
  3. GPU surface. Fundamentally, same as swapping out format. Same as other option.
  4. Add a new magic format - either RGBA or BGRA. Under the hood, impl picks one for device/system. Can use the magic format across all surfaces that need the format. No copy support for this format, can't observe channel ordering. No storage capability, because bgra doesn't have storage support on all platforms. Could add two magic formats. Probably not necessary.
• KN: so options are, do nothing, or magic format. No other proposals.
• CW: strongly suggest that the group keep the spec as it is. Unnecessary copies, but that's what preferred format's for. If we get strong feedback, then post-V1 we can figure out something, but let's not overoptimize for this use case.
• MM: little scared about this. Majority of WebGPU apps will need to interact with the system. Shouldn't have to jump through hoops to write a program that behaves optimally everywhere. Dance of getting preferred format & updating their code to work with it everywhere. Preferred format lets authors do the right thing, but concerned all authors will
• KR: Don't think having to use the preferred format is that onerous. Let's get best practices documents in place and have frameworks have things in place so most rendering pipelines just use the preferred format. We shouldn't overindex on this, and instead gain flexibility post-v1 to address concrete feedback.
• KN: don't think this changes much with preferred format - this is pretty core in the API. You're proposing we change that. Based on …
• MM: making general comment about the API design, not on this specific issue. Shortcoming on how framebuffers are designed per GPU.
• CW: how would you feel if in the future we have both preferred format, and optimal canvas format? Maybe SDR/HDR.
• MM: having both is reasonable solution. Game engines can do the dance - more worried about long tail of developers. Want the design in core, non-optional, to be where developers have to write fewer lines of code.
• KN: having both in core is fine. No problem with that. Do think the preferred format API we have now is necessary. There will be a lot of apps that need to know what the format is so they can do copies, or they're porting a game engine that won't understand our magic formats. Don't have strong feelings about including magic formats in V1.
• MM: pretty compelling argument.
• CW: again - let's try to get to V1 and address things soon after. Magic formats, there are lots of discussions. Can you create textures yourself with them? What about copies? Lots of questions. Would like to defer post-V1 if we are to add magic formats.
• MM: reason I mentioned, if one should be in core it should be the simpler one - I'm worried about the long tail. W.r.t the 2 problems you mentioned - don't let people make textures of the magic format, and don't allow copies.
• KN: I actually think the natural solutions to the problems you mentioned are different from the ones you said, which kind of proves the point.
• CW: this actually doesn't require hardware support, just browser support. If in ~1 year all browsers have it, it's just as good.
• MM: willing to compromise, but only if people don't have to opt in to an extension at device creation time.
• KN: we'd have feature detection, but it wouldn't have to be opt-in.
• CW: consensus: option 1. Kai to make post-V1 issue about magic formats.

• Summary(KN): The concrete use-case is readback after present. Provide an alternate way of doing that that’s less costly, e.g. option to make toDataURL/etc read the display-buffer when there’s no drawing-buffer.
  Q: Can browsers implement that?
  • affects: Does compositingAlphaMode affect using the canvas as an image source? #1847 (comment)
• KN: would like to find this less costly way than preserveDrawingBuffer:true.
• KN: in our impl don't think this is a problem. Hold on to image resource compositor's already using. Allow readback from it.
• KN: but not aware of prior art. Not sure everyone could do this.
• KG: not sure there's always a way to get to that image. (?? kbr is this correct?)
• KN: yes, compositor has it, but page can't get it.
• GT: canvas 2D does this by default; WebGL has the option.
• BJ: we're trying to make an API that has better performance than earlier ones. :)
• KG: you have to go out of your way to add snapshotting. Don't want Google Maps to say preserveDrawingBuffer:true. We usually don't preserve it.
• RC: would it be easier if preserveDrawingBuffer for WebGPU was read-only? Or is it the same implementation difficulty?
• KN: my thought process was going in that direction just now. Proposal I have in mind is rather than preserveDrawingBuffer, something that says: if you readback before getCurrentTexture(), you get the old data. After calling that, you get the new data. Sort of like preserveDrawingBuffer, but can't write over the same contents. Would just swap at some point. Think that's possible.
• RC: if that's easier, makes it more palatable.
• MM: even if we added preserveDrawingBuffer, still requires canvas to opt-in to having it be true. No situation where you can snapshot all canvases in the page. Since there has to be a handshake between canvas you're trying to snapshot and others, another proposal is possible - like Kai's, or instead of setting preserveDrawingBuffer at beginning of time, could say, "preserve the next frame". Think there's a way to do this without falling into WebGL's pitfalls.
• BJ: the desire here's not to do away with the functionality you can get with preserveDrawingBuffer, just a better way. People in Three.js want to add snapshot functionality, they add preserveDrawingBuffer without recognition of the performance implications. Would love if the solution for taking screenshots of WebGPU stuff was to flip a switch that impacts performance of your app for its entire lifetime.
• KR: From a technical standpoint, preserveDrawingBuffer is a quirk because of one API that couldn't read back the buffer after it was presented. After discussions with composition experts, it seems that on all platforms we care about on modern APIs, we can support the usecase seamlessly without a heavy hammer like preserveDrawingBuffer. So let's try to get in that direction.
• GT: I like read-only if that makes it faster. Myles had a comment - the reason I asked the question is developers have a complex page, want to make a screenshot of the whole thing - you could tell them, you have to go into each library you're using and make them screenshottable. Having to go into Unity and make it preserve their drawing buffer?
• KN: this would be like preserveDrawingBuffer but have different semantics.
• GT: can they do that outside the source? preserveDrawingBuffer is low enough level.
• CW: we don't have a concrete proposal right now. Ken has a good point on what proposal to offer. Function call preserving the next frame, making it snapshottable? Can then iterate all WebGPU-rendered canvases and call it on it.
• GT: but you can't iterate all and find out what contexts have been created against canvases. It's destructive if no context has been created.
• CW: let's not iterate on solutions right now but offline.
• KN: I have ideas about where this can go, can make a concrete proposal.

• Agenda(KN): Tentatively struck until after we’ve resolved #2743

• Internationalization Metadata for Human-readable Messages #2780 (we lost this one off the tail of the 2022-04-27 meeting)
• Let's see what canvas issues are solved by the end of this week. Made a lot of progress.
  • Out-of-memory, preserveDrawingBuffer.
  • Let's timebox these.