GPU Web 2024 05 08

GPU Web WG 2024-05-08 Pacific-time

Chair: KG

Scribe: KN/KG

Location: Google Meet

Tentative agenda

• Administrivia
• CTS Update
• “Tacit Resolution” Queue
• Add optional feature clip-distances (add feature with hardcoded limit?) #4588
• Define conventions/rules for features that add new limits (needed to add a limit for clip-distances) #4613
• Allow 2d-array texture view as renderable texture view #4607
• Add optional feature dual_source_blending #4621
• Push constant proposal #4612
• (stretch) Spec allows resolveTarget to be 3d but doesn't allow selecting a depth slice #4600
• (stretch) Does an override need to be statically used by the entry point to be allowed? #4624
• Agenda for next meeting

Attendance

• Apple
  • Mike Wyrzykowski
• Google
  • Kai Ninomiya
• Intel
  • Hao Li
  • Jiawei Shao
  • Shaobo Yan
  • Zhaoming Jiang
• Microsoft
  • Rafael Cintron
• Mozilla
  • Kelsey Gilbert
• Mehmet Oguz Derin
• Myles Maxfield

Administrivia

• This is a Working Group meeting.

CTS Update

• WGSL testing burndown update: 91.6% -> 95.3% of known items
• KN: Our team’s done a great job on adding tests. Main thing left is texture sampling builtins, which are pretty hard to test thoroughly.

“Tacit Resolution” Queue

• Require that every submitted command buffer must be unique #4593
  • KN: FYI. Definitely was the intent, since otherwise we’d have to be able to replay command buffers more than once.
  • KG: In some future where we have re-runnable cbufs, we’d then probably allow this.

Add optional feature clip-distances (add feature with hardcoded limit?) #4588

• JS: One question is whether we should make the limit for number to 8, since that’s what Metal and D3D has as hardcoded.
• KN: I think we could add a limit later if we wanted to. I think the downside is that if we ship this with the hardcoded limit, that might cause minor issues, but it’s very unlikely, because of the reasons you mentioned.
• KG: Sounds reasonable to me
• MW: Believe it’s indeed limited to 8 on Metal.
• JS: I really want someone to review the WGSL side
• KN: Everyone happy to land this feature, once details are ironed out?
• KG: sounds like yes, and OK with hardcoding to 8.
• Consensus: Hardcode max to 8, and we’ll review the WGSL side before landing.

Define conventions/rules for features that add new limits (needed to add a limit for clip-distances) #4613

• KG: With the consensus for hardcoded limit on #4588, we probably don’t immediately need this?
• KN: Yes, but we can still take a look at this. If we don’t have people who really are excited to work on this early, we can just defer this for now.
• KG: We could look but I think Mozilla would rather defer.
• Consensus: Milestone 3 for now.

Allow 2d-array texture view as renderable texture view #4607

• HL: (summary)
• MM: Motivation for this?
• HL: Using 2d array view not allowed in WebGPU but it’s valid in each backend. createView() also will create a 2d-array view by default [on a 2d texture with multiple layers, creating a view with arrayLayerCount: 1] so it is easy to hit.
• KG: Think this sounds like a good idea. Any objections?
• Consensus: Needs PR, but resolved

Add optional feature dual_source_blending #4621

• JS: PR still needs work.
• KN: Make sure we have a milestone on it? Oh, the associated issue is already Milestone 1. Added that milestone to the PR.

Push constant proposal #4612

• SY: Added a new address space called “push_constant”. Similar to uniform but:
  • Each entry point can only use one push_constant binding, for easier layout.
  • Cannot index arrays in push_constant space.
• SY: Question of how large the space can be. We need to reserve some space for the implementation. Limit is small on backends (e.g. root descriptor in d3d12)
• SY: Also question of how to upload push constants. Proposed to add where setBindGroup is available (render pass, compute pass, and render bundle encoders).
• SY: Improved performance over uniform buffer
  • https://github.com/gpuweb/gpuweb/issues/75#issuecomment-2004225261
• KG: Mozilla needs some time to review this
• SY: Alan is asking about lifting the restriction for one push_constant per entry point.
• MM: Isn’t the amount of available space dependent on the number of bind groups (which also take space in the root descriptor)?
  • SY: Yes, d3d12 64 DWORDs. Even a small limit is useful, though prefer to make it larger
  • MM: If you add accounting that bind groups + push constants is under some limit (think this is a good idea) then the mapping from bind groups to root constants needs to be described in our spec. Restricts implementations ability to hoist push constants in/out of tables.
  • SY: Would you mind leaving a comment on the PR?
  • MM: Sure
  • MW: Is there a reason we are designing this proposal instead of setVertexBuffer with dynamic data or similar?
  • MM: 3 or 4 years ago we discussed this; we ended up on the trail of whether push constants was actually faster than putting the data in a buffer. Why can’t it be polyfilled by the application. Not sure if performance was proven to be better. Then the discussion veered off into whether, if we’re going to specify push constants, should we say there are no limits on push constants, and the implementation would only use backend push constants if it was small enough. Otherwise silently promote to a buffer.
  • MW: Do think the performance is better (at least in metal backend for small sizes). Question is why introduce new comment instead of allowing attaching an ArrayBuffer as a vertex buffer.
    • Other thoughts:
      • I mean we could have either:
      • void setPushConstants(uint32_t offset, uint32_t count, AllowSharedBufferSource data);
      • or
      • setVertexBuffer(GPUIndex32 slot, AllowSharedBufferSource data, optional GPUSize64 offset, optional GPUSize64 size);
      • The latter seems simpler so we don't have to rework the GPUSupportedLimits as this will impact those. The backend internally can decide whether or not to create a buffer or use push constants.
      • There are also implications where if this is supported by GPURenderBundle, then we would likely create a buffer in any case
  • MM: In SPIR-V, shader needs to know whether it’s reading from a push constant. Would need to know at compile time where it’s pulling the data from.
  • KG: For why we have setPushConstantU32/I32/F32 instead of just the AllowSharedBufferSource overload, still can be debated.
• KG: (This issue here is M2, so making this M2 also)
• KG: We will take a closer look.

(stretch) Spec allows resolveTarget to be 3d but doesn't allow selecting a depth slice #4600

• KN: (summary)
• HL: Not sure if any motivation for a 2d multisampled render target with a 3d resolve target.
• …
• KG: Jasper and others’ instinct is that this may not work well. There are most likely devices we want to target that would have bugs here. Would want to be cautious about adding this feature, test carefully. So disallow for now.
• (No objections)
• Consensus: Disallow 3d textures in resolveTarget.
• HL: Once we allow 2d array textures in view, want to allow it in resolveTarget?
• KG: I expect that 2d arrays would work fine here, because that’s what VR would do normally. It’s just that 3d is unlikely to work well enough on already-deployed devices.
• KN: Require resolveTarget to be 2d for now (as the spec bugfix) and then allow 2d-array when allowed as part of #4607?
• KG: As long as end state allows 2d-array in both places.
• MM: Who will do the analysis to find out if 3d works?
  • KN: Honestly don’t think it’s important enough anyone needs to investigate it yet.
  • KG: “Investigations welcome” though.

(stretch) Does an override need to be statically used by the entry point to be allowed? #4624

• KN: (summary)
• MM: What’s the reason it has to match “something in the module”?
  • KN: Typo protection mainly? Technically I don’t think it has to, if we wanted to change the spec here from what was previously proposed.
  • MM: Sounds legit.
• KG: Mozilla will look at this offline.

Agenda for next meeting

• Tentatively meet next week since we have many more agenda items. Atlantic time. Probably come back to Pacific time soon afterward.
• Add new items to the list below!
• Agenda requests:
  • Items to revisit
    • Does an override need to be statically used by the entry point to be allowed? #4624
  • Add extended range #4500 (comment)
  • get a copy of the image contents of a context" does not handle case where canvas is unconfigured #4606
  • Should command buffers be invalidated by an invalid submit? #4599
  • (related to the above) Should there be a limit on the number of open GPUCommandEncoder instances? #4622
  • [editorial] Consider if there's a much better name for "image copies" #4573
  • Add synchronous GPUAdapter.info #4550
  • Discussion about feature level API and Compat (no issue yet?)
  • Items to revisit on Pacific time
    • Add optional feature clip-distances (if there are new questions) #4588
    • Add optional feature dual_source_blending #4621
    • Push constant proposal #4612