Chair: CW

Scribe: KR

Location: Google Meet

• Administrivia
• CTS Update
• (make a format tier?) Add optional feature rw-storage-texture-formats-1 #5160
• Allow render bundles to inherit state #5171
• [Immediate Data] Support SetImmediateData() in RenderBundle #5118 (related to #5171)
• Add @builtin(renderbundle_index) #5158 (pause in favor of #5171?)
• Why GPUCommandBuffer and GPUCommandEncoder cannot be reused? #4138
• Add texture component mapping as an optional feature. #5179
• (late question) Compat: Add clarification on BC guarantees for sliced 3D feature #5180 (comment)
• (late) [immediates proposal] Change limit name to be more consistent #5173
• (late) [binding array proposal] Choose a clearer name for binding array size, in BGL #5174
• (stretch) Triage the rest milestone 1 issues
• Agenda for next meeting

• Apple
  • Mike Wyrzykowski
• Google
  • Brandon Jones
  • Corentin Wallez
  • Kai Ninomiya
  • Ken Russell
• Microsoft
  • Rafael Cintron
• Mozilla
  • Jim Blandy
  • Teodor Tanasoaia
• Mehmet Oguz Derin

• TT: PR looks good but now allows some formats to use read-only and write-only access. Commented on that, Kai presented some options.
• TT: Not sure that a -formats-2 extension will in fact be well ordered
  • Right now Tier 1 would always be supported in Tier 2, but maybe not in the future?
  • Tier 3 / 4 for example
• JB: example where these wouldn't be monotonically increasing?
  • TT: Metal - they have read/write tiers. Right now max tier is 2. If they add Tier 3 and later add different formats with different capabilities, and Tier 3 might not be available on machines that don't have those formats
  • CW: Metal texture format support depends on both OS and GPU hardware support [not monotonic]. That's Teo's concern.
• KR: what if we subset things so that the tiers are always monotonically increasing, and make separate extensions for formats that don't have universal support in that framework?
• TT: that could work. Proposal: formats-tier-1 extension · Issue #3837
• CW: think we can do Tier 1 and 2 now, leave room for Tier 3, and we can have other smaller extensions adding other formats / capabilities.
• TT: SGTM
• KN: Tier 1 proposal - storage binding is a subset. Not sure about the other stuff - based on different capabilities. Still probably well ordered. Says it only affect Adreno 500.
• KN: could just have Storage Tier 1 and Tier 2, would be more clearly scoped. Other things in formats-tier-1 proposal could be separate.
• CW: in formats-tier-1, there's addition of storage binding for a bunch of textures. And formats that didn't exist previously, and adding them with storage binding right now. 16-bit normalized formats for example.
  • KN: oh, I missed that those get STORAGE_BINDING.
• TT: do we want to bundle these all together or separate out different functionality?
• KN: think it's OK to bundle things together as long as we're confident in the ecosystem support. Including D3D11 and OpenGL. (You investigated this for some capabilities already.)
• KN: we could also just not change it - OK to have some extensions which overlap.
• CW: format tiers 1 proposal from Teo will go in - we're pretty confident about it. Does storage formats tier1 imply that formats tier1 is always available?
• TT: available to enable, or enabled automatically?
• KN: either way. Just a detail.
• CW: let's just do formats tier 1 and 2, and have 2 enable 1. These are the capabilities which are the future. Doesn't matter that one only adds storage stuff and the other adds more different things. In the future, if we have 64-bit formats - that can be on the side since some devices won't have it. These will be there forever.
• TT: OK.
• KN: OK. Think it's nicer.
• CW: action items:
  • Ask Jiawei to take care of formats tier1
  • Need to double check Teo's investigation, it's been 2 years
• KN: curious what the situation is on OpenGL ES, for Compat.
• KN: actually, in D3D, the format tables don't care about the API version (only FL, feature level). So should be same for 11 and 12.

• CW: Questions around Metal indirect command buffers
• MW: concern here is that if you inherit proper state in Metal, you can't set buffers as part of an indirect command buffer. Could have render bundles in 2 different ways - set inherit state flag, automatically falls back to record/replay; or if you want to use indirect command buffers, you couldn't call SetBindGroup as part of the RenderBundle, limits its usefulness.
• JB: on Metal is there a significant perf advantage to using indirect command buffers?
• MW: mostly in the user mode drivers, CPU perf. Don't have to reencode all the commands. Same amount of work on the GPU side.
• CW: is it an option - if inherited bind groups, split on SetBindGroup calls? Use cases we care about like external textures or rendering the same object in different places in the same render pass - all of these want to use a mixture of inherited bind groups and pre-encoded bind groups. Object pre-encoded, want to render it in both eyes. Need to change top-level bind group for MVP matrix. Option for WebKit when using Metal indirect command buffers - split the command buffer at that point? Set argument buffer, etc. then execute the indirect command buffer. Not sure how much it helps, maybe a lot of indirect command buffers.
• MW: splitting is one option. Another is to take all commands and replay them. Depends on how many SetBindGroup calls are made with inheritBundles set. A few options. A little complicated if you want to SetImmediateData too. Immediate data would be harder to inherit.
• JB: does WebKit currently ever implement RenderBundles as record/replay? You mentioned a fallback, does it exist in code now?
• MW: we have record/replay for all indirect draws because those aren't natively supported in Metal.
• BJ: think that if we can get a reasonable enough developer experience, we can advertise that we'll have to fall back to record/replay in some situations. WebGPU as hosted on browser, would still be valuable. Get rid of validation from impl itself, IPC overhead for multiprocess browsers, etc. Difficult to imagine a RenderBundle mode with all-or-nothing inheritance as being useful. All of my RenderBundle usage have had multiple state binding changes - queue up as much work in this RenderBundle for record/replay as possible. Moves that type of RenderBundle as a single object record/replay, much less useful.
• JB: then the only useful render calls are "draw" and "debug" - less useful.
• BJ: if you can do all your rendering in the RenderBundle with only draw commands - instancing already handles this case. RenderBundle utility goes down if you only have all-or-nothing binding state. (?)
• BJ: put together a proposal - would like to be able to declare at RenderBundle encoding - here are BindGroups and slots I want to inherit. Those are locked. Then you can pass view bindings, etc. Everything else works the same way, can prevalidate things because you know the bindings' layout. At end of RenderBundle execution, the inherited bits don't need to reset.
• KN: thinking about vertex buffer problem - we have to do that anyway.
• MW: relates to 4138 (also on today's agenda) if we have RBs falling back more frequently to record/replay, their usefulness if we do add command buffer reusability dramatically decreases. Two concepts overlap a lot then.
• CW: Brandon's JS in the comment mirrors my thoughts of how this would work. For Metal indirect things - immediates need to be reset. No way to implement that with a Metal indirect thing. Seems hard to inherit partial state of immediates in the RenderBundle, even with record/replay. Only thing we're looking at inheriting is BindGroups. Even vertex buffers might not be as useful. Same for index buffer. Then things like stencil ref.
• CW: big diff between RenderBundles & reusable command buffers - RBs can be put in a RenderPass. In Chromium they're very similar. For devs, can reuse part of a renderpass, rather than the whole thing as in a command buffer.
• BJ: you'll have new texture targets every frame for render targets - no specs around the recycle rate. Hard at command buffer level to record once and repeat it frame after frame.
• MW: re: Brandon's message - the vertex buffer resetting (?) is a good idea.
• BJ: my proposal is that you can set bind groups that aren't inherited, as before.
• MW: yes. Have to run a command which calls SetVertexBuffer on the indirect command buffer before executing it.
• CW: clarifying - BJ's proposal, some BGs are inherited, but never overridden in the RB - and some bind groups which aren't inherited can be set in the BG - that works with Metal indirect CBs?
• MW: BJ's proposal - reserve buffers 0 and 1 as inherited. Those are set during encoding time to some dummy buffer. ExecuteBundles, before bundle's executed - rewrite the ICB to point those dummy buffers to buffers on the renderpass. Now ICB has buffers from render pass, those are passed to …
• CW: so would Metal support executing the same RB multiple times in the same render pass, while overwriting small chunks?
• MW: yes, can overwrite as many times as you want. Would be overridden just before it executes.
• CW: so CPU-side driver optimization in Metal.
• CW: this answers it then. BJ's proposal seems ideal from our impl's POV; also clear to devs in what it does. And if it's implementable on indirect command buffers, that's great.
• JB: surprised, sounds like what MW said we have to re-record indirect command buffer before execution?
• KN: no, modify in place.
• MW: mutated on the GPU side, yes.
• BJ: my proposal here only talks about bind groups. If we did something similar for vertex buffers could Metal support that too? BGs are more useful overall.
• MW: vertex buffers are supported. And changing the viewport, fragment buffers as well.
• KN: vertex buffers in Metal are the same as bind groups, effectively.
• MW: index buffers are just not indirect buffers.
• Discussion about exactly how this mutation occurs on the GPU, and calling the indirect command buffer multiple times per renderpass.
• CW: Brandon can you take this proposal? Seems bind groups, vertex buffers are a yes. Immediate data, no.
• BJ: I can take this and sketch out what vertex buffer mutation would look like as well.
• CW: sounds good.

• CW: seems that with WebKit's implementation strategy this isn't possible.
• MW: that's my understanding.
• KN: are they inherited? Do you get them at all?
• CW: you can make these work by putting them in a buffer and setting them at an offset.
• KN: OK, you can use them in a buffer just not via SetVertexBytes.
• CW: you can modify immediates partially.
• CW: let's move on for now.

• CW: agree to close this?
• General agreement.

• MW: think this is a great idea. Looking at perf traces from Unity WebGPU apps. So much time spent over IPC that we could get rid of if we had reusable functionality.
• CW: that's good news
• JB: your comment back in May 2023 was that underlying APIs don't support reuse.
• CW: our impl doesn't care. That was a concern from other vendors
• JB: analogous to RenderBundles. If we all do record/replay for RBs then we should try to get some of the flexibility we're paying for already. Firefox wants to be able to record command buffers at command encoder finish time. Dawn records at submit; we want to avoid that.
• CW: OK.
• JB: I'd expect over time - Chromium will be under pressure to not do as much work at submit time. Want to encode WebGPU command buffers at command buffer finish too?
• CW: there have been some complaints.
• KN: we can avoid clearing uninitialized resources.
• JB: wgpu does that too. Every command buffer has metadata, which sections of which buffers it reads from and writes too. Compare to state of the buffers, emit just-in-time initialization.
• BJ: MW, you've seen examples of apps where this functionality could be useful. Taking into account things like render targets - in those cases - how much of that could be handled by RenderBundles, esp. if we have more flexible renderbundles down the road? I generally think reuse is fine. But are devs using existing API effectively?
• MW: good question. Think if they used RenderBundles it'd be more efficient. We can work on making RenderBundles more flexible before adding this functionality.
• KN: people might not know the restrictions here. Can't change anything about bindings or attachments.
• CW: let's table this for now and focus on RenderBundle enhancements. Want to discuss impl details in a separate meeting.

• CW: feature request from Filament team (PBR rendering engine). What milestone do we want this in?
  • Might try to see if we support any Mac 1 devices in Chrome. In that case maybe we can add this in core. Is this M1, M2, later?
  • CW: might want to look at this soon if it's supported in all APIs. But maybe not too much effort on it now.
• KN: most work here is figuring out if we can drop Mac1. Would be helpful to know sooner.
  • (MW: thumbs up)

• MOD: proposing sliced 3D, concerns about Compat and OpenGL support. To get around things we propose dropping this requirement in Compat.
• CW: for Compat it's necessary probably. What about: if BC is supported (and sliced BC is always supported in Core), what about lifting that requirement from Core? Thought it would be free, but it isn't.
• MOD: removing from Core API instead of adding to Compat? No problem with that.
• CW: think that's simpler. Not a breaking change. Don't think anyone shipped sliced 3D at the moment.
• KN: no objections.
• KN: how about a separate PR for that?
• MOD: will do.

• CW: Teo's suggestion of immediateSize / maxImmediateSize? Everything's in bytes in WebGPU anyway.
• General agreement.
• Resolved to do this.

• CW: was concerned, for binding arrays, the array size wasn't clear. Maybe related to texture 2D array? Proposal: rename to bindingArraySize. Clear that it isn't a texture array, but a binding array that has its own size.
  • Only declare starting at index 0, because of how Vulkan works.
• General agreement.
• Resolved to do this.

• Please add items here!
• CW is off next week. Since we just completed all these agenda items, maybe cancel next week.
• JB: Moz Graphics team in Toronto next week.
• Next week's meeting cancelled!
• Agenda
  • Mutable bind groups #5186
  • Add inherited Bind Groups to Render Bundles. #5185