Chair: KG

Scribe: JB/KN/KG

Location: Google Meet

• Administrivia
• CTS Update
• Allow index < limits.maxBindGroups in getBindGroupLayout() #5042
• More compat restrictions
  • Compat: float16(32)-renderable multisample support for RGBA16F, R32F, RG32F and RGBA32F: #4983 comment
  • Compat: update new limits proposal. #5034
  • In particular maxXXXInYYStage auto-upgrades maxXXXPerShaderStage in both core and compat. (visa-versa is already true in core)https://github.com/gpuweb/gpuweb/pull/5034
  • [probably nothing more to discuss yet?] Compatibility mode: support devices without integer texture format multisampling #5004
• Compat feature levels and features discussions
  • [landed, is there anything to discuss?] Compatibility Mode: update to use featureLevel. #5012
  • Compat: add "webgpu-core" feature so Compat adapters can be Core-capable #5036
  • How to add features and limits for Compat after Core ships? #4987 (includes hasCompatibilityFeature()+requiredCompatibilityFeatures proposal)
  • Compat: remove GPUAdapter.featureLevel #5037
    • Depends on #5036
  • Add and name Features for all Compat Mode limitations. #5018
• Agenda for next meeting

• Apple
  • Mike Wyrzykowski
• Google
  • Brandon Jones
  • Gregg Tavares
  • Kai Ninomiya
  • Stephen White
• LunarG
  • David Desormeaux
  • Karen Ghavam
  • Mark Young
• Microsoft
  • Rafael Cintron
• Mozilla
  • Jim Blandy
  • Kelsey Gilbert
• Nvidia
  • Anders Leino
• Albin Bernhardsson

• KG: CR snapshot published!
• KG: New charter approved. We are now in indefinite CR extension track!
  • We take Candidate Recommendation Snapshots from time to time (maybe once a year?) whenever we feel we have a good version that we want certified via horizontal review etc. Whenever we want to make a For Real Published Spec.
  • Right now every change is published in a Candidate Recommendation Draft.
  • e.g. when we do compat, subgroups.

• KN: Mostly compat-related test additions. Gregg making storage buffers not rely on previous state, which we were kinda relying on. We also have new tests for the IDL, because Gregg found some differences with our Node bindings. Other additions include EXIF orientation.

• KN: Rather than treating the array of bindgroups as something that can both contain nulls and has a length less than limits.maxBindGroups, this makes it act like it is always an array of length limits.maxBindGroups that may contain nulls.
• MW: This change seems fine, ever-so-slightly breaking, but the likelihood of anyone relying on this is practically zero. Not opposed if there’s agreement to move forward.
• KN: To clarify: the “breaking change” is just that, if you were catching the error before, you won’t get it thrown any more
• KG: Mozilla is fine with this.
• RESOLVED: Let’s move forward with this.

• JB: The comment is too terse, we don’t understand what it entails. Can we get a proper issue filed for this?
• KN: The two new extensions we’re adding, named above, are both in WebGPU core. But they need to expose less functionality than core does. Core requires multi-sampling, but the compat extensions cannot provide that. But yes, we’ll write a proper PR / issue / message on a handkerchief that explains the details.
• Resolved: Waiting on PR to discuss

• In particular maxXXXInYYStage auto-upgrades maxXXXPerShaderStage in both core and compat. (visa-versa is already true in core)
• GT: Already agree but the other update was it’s a bindGroupLayout
• Resolved: Approved.

• Resolved: Wait on PR to remove multisampling of int formats in compat.

• SW:
• JB: Mozilla worries that some of the changes we’re looking at right now in this area are in the area of diminishing returns. We worry that the impact will be diminished because people use it incorrectly.
  • We’ve already done a massive expansion of the reach of webgpu api via compat, and that’s valuable. But adding too many corners of the API here for compat users to be yet more perfect is becoming not worth it.
• SW: So you’re in favor though of #5018 and #5012, but not going further?
• JB: Yes. Rather, I’m happy with no further change. If people want that, Mozilla is ok with that.
• [Discussing other topics first]

• Nothing new to add.

• KN: summary
• MW: I think this is a better proposal than what we had before
• JB: Favorite because of low impact on core-only browsers?
• MW: That, and not requiring bikeshedding all of the names for compat in the near future, have time to decide names, which features are needed, etc.
• JB: Our first choice is no individuation of features at all, in which case this wouldn't be necessary.
• SW: My pros and cons:
  • Pros: separates compat features into their own namespace; core-only easier; unshipping compat easier
  • Cons: Compat code looks different from core code, and pattern doesn't match
  • Purpose is to protect us during a period where not all browsers have synced with the latest spec
• KG: May find us not wanting to [] in some cases. Imagine we hadn't discovered we couldn't do float32-blending by default. If we add that and put it in the spec and a browser hasn't updated yet, users would start getting warnings
• KN: Lets us defer work on un-restricting things that we restricted in Compat.
  • Does not help us if we mess up and failed to identify a restriction that should have been in compat
• JB: CTS still in progress right? Further work in CTS may discover new limitations
• JB: The damage is that there will be [some devices that could have had compat, that cannot because compat requires some capability]
• JB: Not a fan of doing a lot of work for every last sliver of [hardware] audience. Not the end of the world if we can't offer them an adapter.
• KN: Can easily imagine features that are say, 50% of compat. Too big to require in compat, too important to eliminate completely in compat.
  • A lot of WebGL extensions' equivalents fall into this category
• JB:
• KG: Multiple stories for compat… one end is go back as far as you can, minimal featureset. Other is supporting devices that just missed core. Has me spitballing in my head, could we just have a very small number of tiers? (Not to send us down an intense rabbithole)
• SW: Mali for silly reasons can't support storage buffers in .. stages.... A lot of overlap in which major features are supported at what point.
• GT: Think the major features (not limits) that will support a lot of devices are float16-renderable and float32-renderable
• SW: e.g. D3D11 will support texture views. Could be supported.
• JB: All of this needs to be phrased in terms of incremental audience. If we must start discriminating features in compat, that changes my thinking.

• JB: How does this relate to #4987? Do we still want this if we pick that?
• KN: This lets you ask for a compat adapter, look at its feature, decide that if you’re missing something, to then ask for core.
  • So this, if you ask for compat, can give you a core-compatible adapter back if you ask for this feature, but without this feature, it wouldn't be possible to lift all compat limitations.
• BJ: What’s the benefit of this vs asking for core first, else asking for compat? It feels like thtt’s the same functionality, just asking in reverse?
• KN: That would work, but:
  • If it’s a feature that you want, you can check if the [compat] device if it has it.
  • Avoids having to call requestAdapter twice, and the associated logic of picking features and limits etc.
• KN: It’s not a huge advantage, but it does help a little.
• BJ: So si this at device-creation?
• KN: Yes
• BJ: And that would remove the compat validation [on the resulting device?]?
• KN: Right.
• BJ: And if compat not implemented, if you just call requestAdapter with no args or with compat, you get the same thing?

• Depends on #5036

• KN: Will be out in 2 weeks and in 3 weeks
• Plan to meet
• Agenda!
  • Viewport rect must lie entirely within the current attachment size? #373