Chair: KG

Scribe: KG, KN

Location: Google Meet

• Administrivia
• CTS Update
• Loosen viewport validation requirements #5025 (issue #373)
• More compat restrictions
  • Compat: disallow multisampled integer textures #5053
  • Compat: make "float16-renderable" and "float32-renderable" required? #4417 (comment)
  • [depends on #4417] Compat: disallow multisampled f16/f32 textures #5052 (issue #5049)
• Compat feature levels and features discussions (after discussing float16/float32!)
  • (UPDATED) How to add features and limits for Compat after Core ships? #4987
  • Compat: add "webgpu-core" feature so Compat adapters can be Core-capable #5036
  • [depends on #5036] Compat: remove GPUAdapter.featureLevel #5037
  • Add and name Features for all Compat Mode limitations. #5018
• Agenda for next meeting

• Apple
  • Mike Wyrzykowski
• Google
  • Brandon Jones
  • Geoff Lang
  • Gregg Tavares
  • Kai Ninomiya
  • Stephen White
• LunarG
  • Mark Young
• Microsoft
• Mozilla
  • Jim Blandy
  • Kelsey Gilbert
• Nvidia
  • Anders Leino
• Albin Bernhardsson
• Xiaoshen X

• KN: No big updates. Some work on compat.

• BJ: Original restriction was here because of Metal spec at the time, but it was wrong and was removed from Metal. Only complication here is that VK is wishywashy about what the maximums are: Bounds are (at least?) [-maxTex2dSize2,maxTex2dSize2-1]. #5025 matches that.
• JB: Works on all backend APIs? How confident are we that that it works on real devices?
• BJ: Started writing tests but wanted to discuss in WG first.
• JB: Is this possible to polyfill if we encounter a buggy device where it doesn't work?
• BJ: There was some discussion on the issue about polyfilling, I know it's not trivial, might be doable.
• GT: GL doesn't seem to support this. Would need to add a compat restriction
• SW: Talked about polyfilling it on GL but doesn't seem super easy.
• GL: What's the restriction on GL?
• GT: (reading some spec text)
• GL: Negative width/height is a different thing.
• BJ: Negative width/height not added in this PR.
  • AB: Vulkan allows negative height but not negative width.
• GT: Will check outside the meeting, maybe it works.
• MW: Considered how this interacts with foveated rendering or variable-rate rendering (VRR), texture size is much smaller than the viewport size.
• BJ: Think viewport will act as usual - before rasterization -
• MW: In Metal if you set a VRR map and the viewport is going to be larger than the texture size, it probably usually falls within these bounds but not necessarily. Say a 16Kx16K texture… with [a higher density region in the middle][?] viewport will be 32Kx32K
• BJ: (something…) probably wouldn't function at all
• KG: Think we had not considered it, but this change is strictly better than before. Only might need to further improve it later for VRR.
• MW: Agree.
• Approved, needs testing, need to check whether a new Compat restriction needs to be introduced.

• Compat: disallow multisampled integer textures #5053
  • KG: As long as we're not trying to normatively list the formats.
  • KN: Right, it's all integer formats. I will tweak the language to clarify. Once we merge into main spec it will be in the format table so it will be exhaustively listed.
  • Approved with clarification
• Compat: make "float16-renderable" and "float32-renderable" required? #4417 (comment)
  • SW: We can make these capabilities core if we drop support for two old ARM Mali devices: Mali-T720, Mali-T624
  • Resolved: remove these features, require these capabilities in compat.
• [depends on #4417] Compat: disallow multisampled f16/f32 textures #5052 (issue #5049)
  • SW: It turns out that the extensions support some multisampling, but only on r16float and rg16float. Not rgba16float or *32float.
  • SW: No way to collect actual support for those except to query it on real devices. Don't have any databases that have this data.
  • KG: If the specs say we can have multisampling on those formats, just add them. Cool if we find out later we can support rgba16float, but no need to exclude r/rg16float.
  • Resolved: update compat to only be able to multisample these two formats.

• (UPDATED) How to add features and limits for Compat after Core ships? #4987
  • JB: Controversy in the past was that Mozilla preferred to have no features for compat. If some feature were closer to 50% then we would want to expose it. However right now there are no such features proposed. Mozilla would prefer not to take any of this machinery.
  • Kai's doc of code samples: compat init case studies
  • JB: I noticed looking at that, that having a "webgpu-core" feature makes the code look pretty nice. Independent of everything else - having it be an ordinary feature, that everyone would provide, and that you could be auto-upgraded to (not guaranteed to be validated) - but it made the code look nicer. Warm to that proposal.
  • SW: Also in favor of returning adapter.featureLevel?
  • JB: Yes. Agree with Kai's footnote [1] in the doc.
  • GT: I don't see the need for "webgpu-core" in that, back to a year ago, you would just requestAdapter(core) then fall back to requestAdapter(compat).
  • JB: Fine either way, both code samples look OK.
  • BJ: I brought up some concerns last time about it feeling weird and slightly backward. Gave it thought after that, and I didn't think of anything that felt less backward or weird. As Jim pointed out I can see how this allows fairly clean code. Retracting previous "bleh".
  • SW: One thing that became clear with this exercise, if you're willing to have cascading requestAdapter, then we don't need adapter.featureLevel or "webgpu-core".
  • GT: If we add compat features, then if you write code that's compat-only it will fail on core. You'll get upgraded to core without being able to easily see that you were upgraded, and then requesting the compat feature will fail.
  • SW: aside: There are some things in ES3.2 like per-color-target state, that we could expose…
  • KN: Don't think there was any way to totally avoid issues with adding compat features, without having hasCompatibilityFeature.
  • JB: The value of adding the feature depends on how much audience it adds. This audience would be strictly people who require compat but also require this other feature. It seems like a small slice.
  • SW: Have heard that issue with vertex SSBOs but not others yet.
  • GT: And that is solved with limits already.
  • KN: FWIW can add hasCompatibilityFeature in the future. People just have to check it exists before calling it.
  • KG: Should keep in mind how easy things would be to remove. Prefer to
  • KN: Sounds like current proposal is: no adapter.featureLevel, no hasCompatibilityFeature, no compatibility features at all.
  • GT: No way to tell if it's compat except by which requestAdapter you got the adapter from.
  • KG: Should be differentiable without having to know what you asked for. If I hand you my just my GPUDevice.
  • KN: See "Runtime feature detection examples" footers in the spreadsheet.
  • GT: Benefit of "webgpu-core" feature.
  • KG: We will do this in the future when we move optional features to required.
  • JB:
  • GT: requesting "webgpu-core" will fail on a device that doesn't have core …
  • JB:
  • JB: Is it our expectation that in the future some features will become required?
  • KG: Yes, I expect this. Though we haven't done it with WebGL.
  • KN: I also expect this.
  • KG: Features and feature levels are very forward-compatible. If you ask for "compatibility" feature level and get the "webgpu-core" feature, there's no way to ask for compat without core, without some browser flag or something. Thinking that is okay…
  • KN: If you requestAdapter(compat) and then don't enable "webgpu-core", the compat restrictions will be enforced.
  • GT: If you requestDevice w/"webgpu-core", do you also get Core limits?
  • KN: Yes, that's my proposal.
  • JB: Draw up a new PR that clearly explains all the decisions behind it.
  • KN: So proposal is: No adapter.featureLevel, no compatibility features, yes "webgpu-core"?
  • JB/MW/KN: thumbs up
  • KG: Maybe “core” instead of “webgpu-core”?
  • KN: OK with me, just picked "webgpu-core" so it was a different string than the feature level "core".
  • PR needed
• Compat: add "webgpu-core" feature so Compat adapters can be Core-capable #5036
  • (resolved)
• [depends on #5036] Compat: remove GPUAdapter.featureLevel #5037
  • (resolved)
• Add and name Features for all Compat Mode limitations. #5018
  • JB: Now no need to list all of these features, and have Safari expose them?
  • KG: I do want these to have names. Not requestable "Features", but ability to discuss 'flexible texture views'.
  • KN: Want names for the restrictions or names for the features?
  • KG: Names for features OK.
  • KN: And then we can use them for hasCompatibilityFeature if we do add it.
  • SW: Want names for each one, or keep them clustered?
  • KG: Clustered OK.
  • SW: Will these names come into the spec?
  • KG: Might show up as heading/section names.
  • JB: Gives us and people reading the spec a foothold for discussing the differences between Core and Compat.
  • KN: In spec can have a section of "here's what core has that compat doesn't". E.g. subsection titled "Flexible Texture Views".
  • JB: These are editorial concerns.

• Next Meeting?
  • SW: Out for 3.x wks (2/05, 2/12, 2/19, 2/26)
  • KN: Out for 2wks, and Feb26 (2/05, 2/12, 2/26)
  • Can talk about Core stuff on 2/19, if there is any. There is none right now.
  • Let’s come back for a meeting in March, 3/05.
  • Tell Kelsey and Corentin if any issues come up that you need to be discussed in the WG sooner.
• Agenda requests!
  • Index resolution is potentially underspecified #5064
  • maxDynamicFoo should be required to be at most maxFoo in limits #5069
  • Add GPUTextureView support to importExternalTexture() #5068
  • "shader-f16" requirements exclude all Qualcomm devices #5006
  • Triage milestone 1 issues