Chair: CW

Scribe: KN/CW

Location: Google Meet

• Administrivia
• CTS Update
• Mutable bind groups #5186
• Add inherited Bind Groups to Render Bundles. #5185
• Feature request: Support GPUBuffer in GPUBindingResource #5095
• (Updated tables for tier 1 and 2) Add optional feature rw-storage-texture-formats-1 #5160
• (stretch) Triage the rest milestone 1 issues
• Agenda for next meeting

• Google
  • Brandon Jones
  • Corentin Wallez
  • Geoff Lang
  • Kai Ninomiya
  • Ken Russell
  • Stephen White
• LunarG
  • Mark Young
• Microsoft
  • Rafael Cintron
• Mozilla
  • Jim Blandy
• Albin Bernhardsson
• Mehmet Oguz Derin

• Kelsey leaving Mozilla, will keep chairing short term as invited expert, TBD medium/long-term.
• F2F timing constraints
  • September / October in Canada East Coast.
• [TAG] WebGPU Compatibility Mode #1063. Two pieces of feedback:
  • Does it add some fingerprinting capability?
    • Answer is that it should be just the core-features-and-limits at the moment. That's all the fingerprinting that's added.
  • Could restricted features be added back later?
    • SW: We considered this and don't expect to do it.
    • JB: Agree
    • KN: To the question "Is that a decision that your group could take later?", yes.
    • JB: Yes. May do it, just don't plan to.

• CW: Going to be difficult to find something that's nice for developers and okay for implementable.
• KN: Filed the issue because it is a topic that came up a lot wrt to bind group inheritance. It seemed there was a direction we were going towards so filed that.
• CW: Bind group creation is always a hot spot. See it in a bunch of places, also creates JS garbage. So common question is, can we change bind groups? It doesn't match backend binding models well. In D3D12, we can only mutate the bind group on the CPU, and only when the GPU is not using it. Metal, and Vulkan with extensions, are more flexible. So maybe in the future we can provide "pipelined" updates.
• CW: Other constraint is setBindGroup records a pointer to something, a WebGPU bind group, but the actual pointer depends on the implementation. Believe both WebKit and Firefox just tell the driver here's the pointer to my (backend) bindings object. Because of this we can't change the contents of a bind group after the setBindGroup command. …. So pretty constrained. Given these constraints, what can we do that's useful for developers (ergonomic, fast for implementations, doesn't break guarantees). Also, the concern about Bindless, which is going to need something like this. Bind group will be so large that copying the whole thing to modify it isn't practical.
• JB: Trying to understand VK_KHR_push_descriptor. I don't quite understand how it behaves, but looks like you need to know in advance that this particular descriptor set is the one you're going to update dynamically. Not updating an existing normal descriptor set.
• CW: My understanding is it's like push constants, except instead of constants it's descriptors. Very limited, cannot push whole descriptor updates through it. In a way, more like D3D12 root descriptors.
• MY: There are all sorts of ways to do things… descriptor buffers for example.
• CW: AFAICT descriptor buffers are the only way to do GPU→GPU copies of descriptor sets in Vulkan
• CW: Best idea when working on bindless is clone-with-modify. Otherwise, being able to modify the bind group means: deal with internal versioning, confusing API [that seems to modify past references to the bind group but doesn't].
• BJ: Another use case [from Chromium/Skia Graphite] is recording command buffers, bundles, before [texture objects that need to be bound are known].
• AB: To me sounds like that could be solved by render bundle bind group inheritance.
• BJ: Thought so too. They seem to have a lot of resources, [would not fit in inherited bind group(?)]
• AB: Also need information about the bind group in order to generate barriers. Dawn records at submit time, but if you're not, then that's really tricky.
• JB: If you have that many textures, surprised binding arrays aren't what they want. Tons of different bind groups for tons of textures?
• JB: Agree with Albin…. Spec would need to be extremely clear about what's a reference vs copy, what changes would affect what other things…
• CW: Re: binding arrays, Dawn does not implement unsized binding arrays which Graphite would need. Would neet bindless which we don't have yet
• CW: … One design space we rejected early but could work: enqueuing GPU updates to bind groups is not possible on D3D12 and many Vulkan. Doing it as a device command is tricky because is setBindGroup a reference to the bind group or to its contents. So: What if bind group updates were queue operations which are well-ordered with submit(). Implemented by orphaning the bind group's underlying object and making a new one. This is a problem for Firefox's implementation because you need the pointer to the actual data when setBindGroup is called (at command buffer recording). Bit silly idea: add a flag to bind group creation to say it's mutable, then when wgpu sees that, it reserves a staging allocation [in the descriptor set pool] and points to that. Then before executing the command buffer, copy the bind group data into the staging allocation.
  • JB: vkCmdUpdateDescriptorSets?
  • CW: Not a Cmd.
  • JB: …
  • CW: Wait, it requires "update after bind" capability.
  • BJ: Still Albin's concern of generating resource barriers.
• MY: FYI, there is a way in Vulkan to update bound DescriptorSets in a command-buffer: vkCmdBindDescriptorSets.
• KN: Have good ideas of how this could work? If not, close?
• CW: Think it's very useful to have "clone and update"
• KN: Can we make the conclusion that we won't have (soon) anything that can affect already-recorded bundles or command buffers?
• CW/JB: Think so.

• BJ: Given Mike's not here probably won't dive too deep, but some things worth socializing. I've written up a spec draft. The big thing is I have it as a feature, Corentin wondered if it could be core. Also, currently I have individual bind group slots inheritable, Corentin suggested it could be a contiguous sequence instead of sparse. Probably bit better for performance, about same for ergonomics.
• CW: In WebGPU and Vulkan there's this non-normative suggestion that lower bind groups should be changed less frequently. Doesn't matter for bindless hardware, but bindful hardware would need to repack all the bindings. But this is a backward looking concept… so happy to remove that suggestion.
• JB: Similar to secondary command buffers, not a performance win, so take the flexibility 🙂. Placeholders, having the layout certainly seems necessary for validation. Concern [with the placeholder bind group objects]: we have very few bind groups (4), constraining the flexibility by tying it to this limit?
• BJ: For placeholder BGL, thinking about removing that with some restructuring of the validation.
• BJ: For the limitation of the number of bind groups themselves, think it is useful for a bunch of use cases. Not so useful for Graphite with 100 textures. But for example it is useful to change a matrix or a few things per view of an object. These are the use cases that inheritance will help with. Won't help fill parametrization but at least some
• CW: Also solves the previously described use case with external texture.
• CW: Babylon.js has some models that are extremely static (e.g. chunk of the map) and could be in a render bundle. They can do this by updating the model-view-projection matrix in a bound bundle for example. Even this case benefits from inheritance, as each bundle doesn't have to bind the MVP matrix separately, they can just inherit it.
• BJ: Can also modify the contents of an indirect buffer, e.g. I do this in my frustum culling sample.
• BJ: Temperature check, is anyone opposed to this being core rather than a new feature?
• JB: Only needs to be a feature if it's a hardware/backend limitation.

• JB: Thumbs up
• CW: Approved!

• CW: Jiawei wrote up tables for texture-formats-tier1 and texture-formats-tier2: https://github.com/gpuweb/gpuweb/pull/5160#issuecomment-2880050816
• CW: Please review for next meeting. (don't think PR is updated yet, so please review these comments) Any comments so far? (Not yet.)

• CW: Don't know that we have enough for next week, can make progress offline on most things. So unless small topics or easy things come up, suggest cancelling next week. (WGSL already cancelled next week)
• Agenda requests!:
  • (FYI) Add [AllowShared] to setBindGroup #5202
  • Auto-enable rg11b10ufloat-renderable with texture-formats-tier1 #5200
  • Determine whether we can drop MTLGPUFamilyMac1 support #5187
  • Consider lifting size%4 requirement of copyBufferToBuffer and writeBuffer #5203
  • View component mapping (Chromium has data about MTLFamilyMac1)