Chair: CW

Scribe: KN mostly

Location: Google Meet

• Administrivia
• CTS Update
• setBindGroup should accept ArrayBuffer (AllowSharedBufferSource) for dynamicOffsetsData #5212
• Add texture component swizzle proposal #5217
• Error reporting for unbalanced compute/render passes does not match implementations #5207
• Feature Request: Let you pass a GPUTexture everywhere a GPUTextureView is currently used #5215
• (revisit) Consider lifting size%4 requirement of copyBufferToBuffer and writeBuffer #5203
• Agenda for next meeting

• Apple
  • Mike Wyrzykowski
• Google
  • Corentin Wallez
  • Geoff Lang
  • Gregg Tavares
  • Kai Ninomiya
• Mozilla
  • Jim Blandy
  • Teodor Tanasoaia
• Albin Bernhardsson

• Exciting Firefox and Safari progress!
• F2F
  • CW: Is 2 days enough?
  • JB: One we did at apple might have been 3 days worth of content
  • CW: Waterloo (Kitchener), Toronto, or Montreal? Google could host in Waterloo or Montreal, maybe Toronto. Unless Mozilla wants to host in Toronto.
  • GL/JB: Prefer Toronto over Waterloo for travel.

• JB: the reporter's motivation seems to want to avoid creating garbage when using it from WASM but our API already creates a bunch of garbage with descriptors, encoders, etc. Their concern about recreating the ArrayBufferView seems like it won't fix that issue.
• KN: Only platform objects are a problem for garbage but not objects that are only part of the VM.
• KN: Also surprisingly in all browsers TypedArray are somewhat expensive to create. 100x more expensive than you would expect. However don't know what the problem is for the reporter because you only need to recreate the TypedArray when the WASM memory is recreated. We could easily SharedArrayBuffer but unclear right now what is the problem it would solve.
• JB: Doesn't WASI address the issue of calling APIs from WASM without creating garbage?
• KN: Yes, so unclear why the report mentions both JS and WASI. Didn't know
• CW: For consistency wouldn't it make sense to add SharedArrayBuffer like all other uses in webgpu's IDL
• KN: Different because it takes an array of numbers (as either a sequence or a Uint32Array) and not a bag of bytes. So here is about adding AllowSharedBufferSource. Don't want to do that because then you can pass things like Float32Array and Uint16Array. Instead, we would want to change the current [AllowShared] Uint32Array to ArrayBuffer or SharedArrayBuffer or [AllowShared] Uint32Array.
• CW: Issue not clear enough and the proposed fix isn't a clear yes for consistency so come back to it if we have more data.

• CW: MW commented that "identity" was redundant
• KN: Guessing Vulkan only has that because it's easier to initialize in C. We don't have that problem.
• Agreement that it is redundant and should be removed.
• JB: This is something that all the platforms provide so it must be useful and we should have it.

• JB: Believe that the intent of the spec is to tell developers that they should not expect errors to be called on every encoder call because we will only tell you at the end of the pass. Helps implementations buffer stuff locally. However there are cases where each individual call check the state of the encoder and raise an error. So it seems that the spec is not consistent? And it seems implementations + CTS agree with each other but not with the spec.
• KN: Haven't had time to look at it, not surprised that there are inconsistencies. The reason why sometimes the error goes to the device is that sometimes it is not possible to invalidate the encoder, because it was already finished, or (IIRC) because you tried to create two passes on the same encoder. One of the passes is invalid so maybe it reports errors to the device.
• JB: So the general idea is that you can can encode commands and have an error in the command stream, and will get you the error in .finish. But if you encode on a finished encoder we can no longer notify you that something is wrong so we trigger the error on the device.
• TT: You can create an encoder with error commands but never call finish() in which case you'd never get the error as well. So there is a parallel with encoding on a finished encoder.
• CW: Our implementation (which passes whatever is in the CTS) forwards encoding errors to the device only when the encoder is finished.
• CW: There's a difference between (a) making an error encoder and (b) never using it (which silences errors) and finishing an encoder and never using it. (a) is benign because worst case they did extra work that's useless - and we can't tell the difference. (b) we know for sure is a mistake because the encoder is already closed.
• JB: Might be nice if an implementation produced a log message if cleaning up a command encoder that was never finished.
• CW: Let's revisit.

• GT: (summary)
• JB: Jasper thinks it's valuable to explicitly create the texture view.
• CW: Think it's clear we should either allow GPUTexture or fix our error messages.
• AB: Agree… the difference would be passing all of a buffer is always valid, passing all of a texture is not. For example rendering to a layer.
  • GT: That's OK, we can report that error clearly, you have to create a view.
  • TT: What happens internally?
  • CW: We call .createView() and use its defaults. Report an error based on that view.
• MW: Agree with Gregg, think this is redundant especially on canvas textures which generally never need anything other than the default view.
• CW: Seems concerns are ergonomics vs forcing people to learn the concepts.
• GT: It improves the error message. Right now browser thinks it's supposed to be a GPUBufferBinding and the error message doesn't make sense.
• CW: Think browsers will just implicitly create the view and lose the information about whether a texture or a texture view was passed. If we want a nice error message that knows that information, requires extra plumbing.
• KN: We should fix this error message regardless, let's discuss assuming we fix it.
• GT: OK. Frustration is this happens very often, we already know what the developer meant, why throw an error to force them to do the busywork of typing .createView()?
• TT: Someone from Bevy mentioned that … [see comment]
• JB: Difference isn't observable and the spec isn't a teaching tool.
• KN: My main concern is not about messages in error cases, but success cases where both views would be valid.
• CW: Can we have weak consensus to do this?
• KN: OK with me.
• JB/MW: OK with us.

• KN: We have a little more information on exactly where the validation happens
• KN: Refresher: metal, only, has validation that requires buffer-to-buffer copy sizes must be a multiple of four. No other API has this restriction. And it only applies to macOS, not iOS, which is weird, because usually it’s an Apple Silicon vs. other issue. It seems like it’s probably fine to use unaligned sizes on Apple Silicon, and just require a workaround on old Intel macs
• MW: That's true, one can confirm with the validation layers that Apple Silicon Macs allow non-multiple-of-4 sizes. Have not confirmed on older macs whether it actually works - the validation layer will enforce it, but not sure about the Intel or AMD drivers.
• KN: If we assume that this is only invalid on non-Apple Silicon macs, do we want to lift this restriction, and require a workaround on older macs?
• MW: How easy is the workaround if you’re doing updates into the middle of the buffer, and the device is used on the queue timeline? It wasn’t clear to me how you’d actually copy those extra bytes without accidentally overwriting bytes you didn’t mean to
• KN: We could use texture copy for this, because texture copies don’t have this restriction. It only has to deal with 1, 2, or 3 bytes. You create a textureview on the source buffer, and then you copyTextureToBuffer from that into the destination buffer
• MW: Is that going to require linear texture support? That’s not available on the mac 1.
• KN: I don’t know if texture views on buffers require that.
• MW: Assuming you could create that texture view, that would work. But that seems to require Mac 2. So if you can’t create a texture view on a buffer in Mac 1, then that would be a problem.
• KN: We’d definitely need to try this.
• MW: “Texture view” on a buffer means that you can create a texture that draws its texels from the buffer’s contents. I don’t know if that’s considered a linear texture or not.
  • https://developer.apple.com/documentation/metal/mtlbuffer/maketexture(descriptor:offset:bytesperrow:)?language=objc
• JB: Sounds like we need some experimentation with implementations, to make sure this actually works
• KN: If there’s no opposition, then we should try to implement it. We probably won’t get to it soon.
• JB: Mozilla would like to lift the restriction
• GL: Even if it’s a tiny bit slower, the devices that need the workaround are very rare.
• KN: At worst, we could actually allocate a temporary texture. The “view” would be a more efficient workaround.
• AB: How are we escaping the alignment requirement, exactly?
• KN: The offset is still restricted, we’re only using the texture view to finagle the size requirement
• CONCLUSION: We have three possible implementations, experimentation is needed but probably we’ll do this

• Probably not meeting next week. We'll see when next one is.
• Agenda requests!
  • Support for gl_PrimitiveID / SV_PrimitiveID -like construct? #1786
  • Support Resolve for 16unorm and 16snorm in texture-formats-tier1 #5237