Chair: CW
Scribe: KR
Location: Google Meet

• Administrivia
• CTS Update
• Add missing fragment input built-ins to "validating inter-stage interfaces" algorithm #5337
• Should texture swizzle move usage restrictions from createView to createBindGroup/beginRenderPass? #5298
• Validation fails to reject out-of-range fragment shader output locations #5341
• Error reporting for unbalanced compute/render passes does not match implementations #5207
• [immediates] minimum maxImmediateSize should be 16? #5320
• Triage issues without milestones
• Milestone 2 API issues triage
• Agenda for next meeting

• Apple
  • Mike Wyrzykowski
• Google
  • Brandon Jones
  • Corentin Wallez
  • Geoff Lang
  • Ken Russell
  • Stephen White
• Microsoft
  • Rafael Cintron
• Mozilla
  • Jim Blandy
• Nvidia
  • Anders Leino
  • Markus Tavenrath
• Albin Bernhardsson
• Oserebameh Beckley

• Have 3 new invited experts!
  • Lee Mighdoll, Mathias, Stefan from WESL
  • Lets them make contributions to the meetings
• Talking with Jim - More proposals ongoing - bindless, texture swizzle, Alan has a bunch of items on WGSL side
  • Should use the proposals/ folder a lot more
  • For anything non-trivial. Any feature-level stuff. Make an investigation, land it. Low-friction. File a tracking issue, point to it. Then group can work on the proposals/ folder to get consensus, etc.
  • And we can track work that needs to happen with Github child issues (🆕!).

• Nothing this week

• JB: going over this limit in Vulkan is UB. No better alternative than to change WebGPU's validation to include these 3 builtins in the count which it enforces. Recent additions. It is a breaking change, but hopefully Compat impact is relatively small.
• CW: Compat risk seems low, and this is a bug fix. THink we should add it.
• MW: Thumbs up
• Consensus: go and do this ASAP so that we don't increase the Compat risk.

• MW: seems a little odd to allow explicitly passing a usage on createRenderTarget with a non-default swizzle because then we create a texture invalid in all use cases. But don't feel strongly about this.
• JB: what you said is how we feel. What is good customer service? Kai's argument for consistency is a strong one, but we have precedent. Doing the validation in beginRenderPass is fine. That's what I understand to be Gregg's option #2, which is Kai's first choice.
• CW: talking with Gregg - feels his concerns have been heard by the group. He's OK with any solution. Kai likewise, but has a pref for option #2. Consistency with rest of renderability makes sense. All choices are fine, but this one keeping consistency is probably better. François will be happy. 🙂
• CW: let's go with validating at beginRenderPass.
• BJ: does this change our opinion on some of the existing validation in createView around storage binding, etc. usage? Having to use a format that matches with those?
• MW: it does seem odd - that you have render attachment with an unrenderable format - I do acknowledge the inconsistency.
• CW: we could try to address the inconsistency with the format stuff later. Or say that format stuff is different from the usage. Feel if we solve the inconsistency it has to be in the direction of loosening the validation. Ergonomic improvement, if they care enough it or hit it in practice, they can raise it.
• BJ: OK.
• CW: thanks everyone for finally reaching resolution on this.

• CW: never validate that what WGSL exposes is less than the limit.
• JB: Kai confirms it's just an omission.
• CW: will just add the validation to the spec.
• MW: any concerns with eventually trying to precompile shaders? Or ship intermediate representations of shaders? Value might not be known at that stage.
• CW: no plan for precompiled shaders at all. Not sure we'll get there ever. (Validation is always required for incoming shaders.)
• MW: OK, thanks.

• CW: concern raised by Andy.
• JB: you have a command encoder, begin a compute pass, then begin another compute pass. Encoder's now invalid. Looking at language of validation for compute pass end - it will say "if the state isn't the way we expected, raise a validation error". The other validation says, invalidate the encoder. Surprising behavior. A deviation from the push/popErrorScope pattern. Fix we'd recommend - make the spec match the implementations. Invalidate the encoder on end() instead of raising an error.
• CW: sounds fine, app is already in error case. Though it's a breaking change, the compat issues will be miniscule. However - what happens when commands are encoded after encoder.finish()? FF passes the test because Andy added them, but Chromium doesn't. Behavior difference between these two browsers. I believe the CTS and FF assume the errors after finish() will immediately go to the device. Either to ErrorScope, or unhandled error handler. Think in Chromium we ignore the error. Have to spec something.
• BJ: recall there's some intention here that: in the middle of a pass, we'd invalidate things, and then the validation error'd be surfaced once we end the pass. Don't remember the logic. At least some intent behind the pattern. Not sure it's well stated. Hard time tracing it. Worth looking into more? Within passes, it's invalidate - then at end of pass, raise validation errors. Need to dig further.
• MW: think we should make sure the spec matches impls. My reading - it's confusingly worded.
• JB: understand Brandon's intent. When you call end() in this scenario, you've already started a second pass on the command encoder without ending the first one. First one's already invalid. Think behavior you want: if the encoder's already marked invalid, there's already an error on it, calling end() on it doesn't do anything else. Only raise validation error after finish(). Maybe spec's trying to say - if finish()'s been called on encoder, raise error when calling end() on the pass encoder. (there was more here that Ken didn't get)
• BJ: that feels right to me. Want to talk with Kai.
• CW: one thing difficult in spec, pass encoders use the "validate the encoder state" on "this". Sometimes it also talks about the parent encoder. There's some difficulty here because there are multiple encoders which do things. We agree we want all errors to be reported, if before finish() they should be reported at finish(), and after, they're raised as validation errors on the device. This is a mess and we should get it right. Fix CTS and impls to get this behavior & spec.

• CW: running out of slots in the root signature. There are some builtin immediates. Have 36 bytes of space in the root signature. More engineering, we could gain 32 more bytes, so 64 bytes of immediates. More than that, have to spill immediates to a buffer. Have staging buffer, etc.
• JB: your comment from last week - that's talking about what you could get if you did the eng work? Not what you're able to get right now?
• CW: yes. Right now we have 36 bytes free. Could get 44 more by doing things, one of them is very complicated. I'm happy to gate shipping immediates on doing this engineering.
• JB: 64 is easy for Firefox to get.
• CW: and think there isn't a constraint on Metal.
• CW: let's go with 64 and we'll optimize things. E.g., no change compared to the current proposal.

• Note, these are a subset of the ones discussed & triaged
• #5316 WGSL NaN support
  • MW: how would we do this? WGSL assumes NaNs don't exist, to allow for fastmath
  • KR: sounds like a good question for the WGSL working group.
• #5281 Support for YUV textures
  • CW: Twitch want to sample luma/chroma directly
  • Milestone 3, but actually WGSL
• Only 32 timestamp queries allowed on Metal MacOS? #5261
  • MW: Safari shipped the workaround for this, we don't notice any issues with it
  • CW: will close this after this meeting
• How to support HTML-in-Canvas in WebGPU #5251
  • CW: Milestone 4+
  • KR: sounds fine, I'm working with the Chromium team prototyping this and will field questions from them.
• Profiling copyTextureToTexture() etc. #5225
  • BJ: hard to justify if we're just spitting out numbers that don't make sense
  • JB: would like a schedule spit out
  • CW: need platform specific tools then. Metal debugger, NVIDIA NSight.
  • JB: timestamp "attached to" a particular operation.
  • KR: is there any possibility of using native tooling to get this info and surface it up to the web?
  • MW: no reliable way to get this info on Metal.
  • CW: let's just not attempt to solve this problem. Think it will not give people the info they want. All game industry discussion - how to schedule things so they can overlap. They don't measure the speed of operations individually, but how things overlap with other things.

• Start at Issue #4446 next time.

• Please add items here. Corentin will add items for bindless.