Chair: CW

Scribe: KR

Location: Google Meet

• Administrivia
• CTS Update
• Confidence in direction of WebGPU proposals (for webgpu.h v1)
  • [try for v1] Add immediates (push constants) to API #386
  • [try for v1] Add binding arrays to API #387
• Specify that ASTC Sliced 3D feature requires ASTC feature #5169
• Add optional feature storage-texture-format-tier2 #5160
• Add @builtin(renderbundle_index) #5158
• copyExternalImageToTexture with byte-exact uint format #5157
• Triage the rest milestone 1 issues
• Agenda for next meeting

• Apple
  • Mike Wyrzykowski
• Google
  • Antonio Maiorano
  • Brandon Jones
  • Corentin Wallez
  • Geoff Lang
  • Kai Ninomiya
  • Ken Russell
  • Loko Kung
• Mozilla
  • Jim Blandy
• Albin Bernhardsson
• Mehmet Oguz Derin

• Antonio's question about inlining the LICENSE files.
  • Vastly simplifies Chromium's tooling. The WebGPU IDL file is extracted during the build and in the gh-pages branch to build the node.js bindings for Dawn.
  • Alternative would be to have a second Github branch just for the iDL, and the license file just for that IDL.
  • JB: seems fine to add separate sections for the separate licenses in LICENSE.md.
  • MW: no concerns from Apple's side.

• KN: fixed the camera capture tests! They generally need either a real webcam or the ability to feed in a video as a fake webcam stream at the browser level.
• Tests for 3D compressed textures too.

• [try for v1] Add immediates (push constants) to API #386
  • JB: we think the API for push constants seems straightforward and unlikely to change. The validation rules might change, but the API would not.
  • KN: we only care about the API surface since that's what goes in the header.
  • CW: specific question: how confident are we in the name "immediate data range byte size" in the header?
    • JB: confident
  • CW: rest of C header can wait. SetImmediate, etc., is a non-breaking addition.
• [try for v1] Add binding arrays to API #387
  • JB: this feels like a more complex change to the API and WGSL spec
  • KN: we just haven't discussed it as much here.
  • CW: this is fixed-size binding array.
  • JB: we're strictly concerned with changes to structs, not adding functions? So the only interesting addition is adding arraySize to GPUBindGroupLayoutEntry? That doesn’t sound so bad.

• KN: summary
• MW: thumbs up
• Approved

• JB: CW's last comment on the PR has 2 parenthesized clauses, we didn't understand.
• CW: looking at the table: Teo's texture-storage-tier1 has been merged in core. Tier 2 is things that are guaranteed by the base Vulkan spec. These are the only things we can support on ES 3.1. Everything else supports Tier 2 and 3. My suggestion: add 1 optional feature instead of many, combining tiers 2 and 3. Matches Metal RW tier 2. Matches D3D12's bundle of supported formats. Supported on essentially all Vulkan devices. If we ever want to add support for this optional feature on Compat, we'd need to say - this optional feature doesn't add these things. But don't know how many optional features we want to add one thing to core and another thing to compat.
• JB: got it. Is it important that Compat be able to use more of these formats and RW storage things? If so then we need to bifurcate the set.
• KN: think it'd be fine to have this add a different set to Compat. Compat removes capabilities from the core spec, so it's OK to have it remove capabilities from a feature too.
• JB: sounds reasonable.
• JB: we had 2 other comments. This is sort of tier1.
• KN: I requested it be renamed to tier2 because we already have RW storage textures / some of these features. We used to have 0 RW storage textures in core, but now that we do, tier1 should be the first one IMO.
• JB: so you think it's understood that Core is "Tier 1"?
• KN: think so. I'm OK either way.
• JB: solely asking for clarity. Also: we really wanted RW in the name. We have "read", and "write" - these are newly available for read-write usage.
• KN: depends on whether we merge tier3. tier3 is not read-write. (EDIT: this was wrong)
• BJ: Mild preference against "Tier 2", due to the potential confusion Jim brought up for users wondering where "Tier 1" is.
• CW: Vulkan doesn't distinguish between storage-read and storage-write.
• KN: in Jiawei's table/description, I thought it had these as read-only in an earlier revision. Not sure why. My misunderstanding, these are all read-write. Calling this "read-write" does make sense.
• BJ: move away from "tier" naming? feature / package level 1? tier 2 feels weird if there's no explicitly-named tier 1.
• CW: D3D and Metal have a bunch of tiers - think people in the graphics industry are used to the terminology.
• BJ: at least going with a tier 1 for this would stick with the established Metal precedent.
• JB: I'm fine with tier 1.
• CW: OK, let's try that.
• KN: do we want to make it specific? read-write-storage-format-tier1? or storage-texture-tier1? prefer the latter.
• BJ: think it's fine to simplify the name as long as the features are monotonically increasing. If the tiers all stack one on top of the other, it's fine.
• JB: because it's the name of a feature, we could leave out "tier" - "(rw-?)storage-texture-formats-1".
• CW: sure. Let's leave naming to the editors from here.

• CW: bunch of discussion on this. Jasper, etc. came up with concerns about how this changes executeBundle([A,B]) is different from executeBundle(A); executeBundle(B);
• BJ: got feedback from a couple people that RBs would be more useful if you can e.g. render two almost-identical viewports. To communicate the separate view matrices into the bundles - have to introduce a bubble in your render pipeline. Easy to discern if you could inherit just one index from the outside world, the view index.
• BJ: also hard to use these with external textures. These invalidate the associated bindgroup really quickly. Building a RenderBundle doesn't make sense because you'll be able to render 1-2 frames max.
• BJ: this proposal doesn't address the second use case but does address the first.
• BJ: question about executing the same bundle N times.
• BJ: Think this could also be really easily handled with SetImmediateDataRange and just don't invalidate the renderbundle. Then you could have your own user-level renderbundle index. Know how much immediate data you need in order to execute this bundle? So if we're on the cusp of immediate data, maybe we don't need this.
• JB: we were also thinking immediate data could handle this. We were concerned about indices being fragile; if you delete something earlier in your render pass then the index would point to the wrong data. An immediate is very clear.
• JB: interesting analogy - we're all implementing RenderBundles as record/replay. That's a little like macro expansion. Splicing commands into the middle of something. Reason it's not a problem - people hate macro expansion because the interior of the macro gets influenced by stuff around it unexpectedly. Our current fully-insulated RenderBundle design has a nice property - they aren't macro-like. Don't have to look inside them to know what they'll do to their state, or what surrounding state they're sensitive to. If we let RenderBundles be influenced by surrounding code we open this can of worms. If we do let RBs be influenced by immediate data, we can declare this at RenderBundle creation time. (CW: thumbs up.) Then we can verify that you supply that immediate value. Behaves more like a function. Last step - maybe RenderBundleEncoder should have set immediate value; and here, introduce the immediate value from the ambient state. Then people could rearrange RenderBundle interiors and not have to put the immediate stuff up front. Just think we should protect this insulation property of RenderBundles.
• CW: GL display lists had this problem - like a macro expansion - were unworkable. Strong +1 to this idea. I would like to have RenderBundleDescriptor inherit certain parts of BindGroupLayout. Would like to hear from Mike. WebKit uses Metal indirect command buffers - not sure it can support inheriting immediates. BindGroups, yes.
• MW: like the idea. Yes, need to see feasibility of implementing this with indirect command buffers.
• CW: this would be great - address Gregg's and Brandon's use cases. If we could have BindGroups that would be more general than immediate data.
• BJ: agree.
• KN: do we use SetVertexBytes to implement immediates on Metal?
• CW: yes. On WebKit think it might be a buffer binding. Questions about what happens if you encode the same RenderBundle multiple times. Need multiple buffers?
• CW: so do we start some work where we add some inheritance to RenderBundles for BindGroups, and study whether we can do it for immediates?
• (thumbs up all around)
• CW: let's close this issue, very interesting data, and we want to add a more general feature like "controlled inheritance".
• BJ: was thinking about C++ lambdas. Specify exactly the bits you want from the surrounding environment.
• KN: Metal does have individual flags for what gets inherited.
• CW: when you create the indirect command (buffer?) you can say "inherits textures, samplers or buffers". These are the only flags you can pass. Inherit buffers = inherit argument buffers. No way to say - you inherit SetBytes. And if a new SetBytes is done later it only affects a part. That's why immediates are a bit tricky.
  • KN: inheritBuffers and inheritPipelineState (from #382)
  • KN: Is that enough for bind groups?
  • CW: A bind group is an argument buffer so that's sufficient.
• BJ: conceptually swapping out a BindGroup. Could denote at recording time that a given group index must use a specific bindGroupLayout. This would allow validation while recording and at execution time.
• CW: Yes, that’s the most likely shape.

• KN: want to get feedback from the requester before we make a decision. Want to copy in data losslessly from PNGs in particular. Think this is complicated - if we want a guarantee whether it will be lossless, validating is a can of worms because then we are validating things that are mathematically approximate. I don't know why they need this because copying to unorm is lossless. If something's missing in copying to unorms we should fix this. Problem with 16-bit PNGs because we don't have 16-bit unorm formats. Can use floating-point textures as a workaround.
• CW: it's fine, we don't have to add this immediately.

• Nothing specific yet, so let's see if anything comes up.
• (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
• (stretch) Triage the rest milestone 1 issues