Minutes 2021 09 20

GPU Web 2021-09-20

Chair: Corentin

Scribe: Ken / Kai / Corentin / Jeff / others

Location: Google Meet

Tentative agenda

• TPAC meetings
• CTS updates
• Milestone triage (timebox 15m) #2073
• Add defaults for GPUTextureSampleType in the default pipeline layout #2078
• texture_2d_depth for loading depth values might be unnecessary? #2094
• Shader-visible entities occupying multiple locations #1733
• (stretch) Should depth-stencil render attachments require views to have aspect = "all" for combined depth-stencil formats? #2062 (@kvark's comment with RenderBundle proposal)
• (stretch) Consider making ShaderModule compilation errors special #2119
• Agenda for next meeting

Attendance

• Apple
  • Myles C. Maxfield
• Google
  • Austin Eng
  • Brandon Jones
  • Corentin Wallez
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
  • Loko Kung
  • Shrek Shao
• Microsoft
  • Damyan Pepper
  • Rafael Cintron
• Mozilla
  • Dzmitry Malyshau
  • Jeff Gilbert
• Michael Shannon
• Mehmet Oguz Derin
• Timo de Kort

TPAC meetings

• CW: W3C meetings coming up:
  • TPAC week(s?) (Virtual). FD was saying groups are encouraged to tag some regular meetings as “TPAC” so anyone can join and can discuss wider topics. Unless major concerns we’ll just tag meetings during TPAC and some extra people will be able to add agenda items for those meetings.
  • Some meeting between W3C / video/tv standards group. Call for content. WebGPU explicitly called out as having possibly relevant things. Checking if Google has anything to talk about there.
  • Advisory Committee (AC) lighting talk? TPAC tech demos?
    • JG: Possibly filled up
    • CW: Think call for content open still/again
    • CW: Fairly official, group should probably thumbs-up
    • JG: Latest status is that it is for “possible demos on Web technologies for TPAC”.
    • CW: call for content deadline almost past, but flexible. Let Francois Daoust know.

CTS updates

• KN: In the past week there's been work from DN and SM on WGSL testing to get more coverage of builtin function behavior. Finally some WGSL coverage!
• DM: chomping through the CTS. Few issues blocking most of the tests, working through them. Hope to start contributing eventually.

Milestone triage (timebox 15m) #2073

• MM: What happened to prioritization spreadsheet
• (it’s here: https://docs.google.com/spreadsheets/d/19jeGI3uLwVQryUmW12rxaWJe4FTbFBwVi-uEGdwhLQ8 )
• CW: next week, planning to update with new ideas/priorities. You can do it now.
• CW: priorities spreadsheet helped inform V1, etc. - can sort stuff - but right now need to make decisions about what goes into V1. A tool which we can use to do triage.
  • CW: let's also close out issues we think are resolved.
• #2111 - compute shader pipelines are not cached
  • CW: it's already in the Chromium issue tracker.
• #2100 - depth_clamp on D3D12
  • Optional features - want to have spec'ed correctly and available on V1? Or punt this if it slows us down?
  • DM: small and useful feature I'd like to see in V1. (Candidate recommendation and later).
  • CW: think if D3D behavior's different we can paper over it. Think this should be in V1.
  • KN: not sure we can paper over it - but can make more of an attempt.
• #1961 - using structured buffers in HLSL
  • DM: think we can close it. Some limitations in StructuredBuffer. Only thing they save us is implementation cost, and we and Google have already paid that cost.
• #1925 - DX12 impl friction - meta-bug
  • DM: there'll be more things in this. As long as not milestoned with anything urgent, can keep it open.
  • MM: keep open as investigation?
  • DM: OK.
• #1907 - draw-time validation
  • DM: investigation as well.
• #1884 - make error scope objects have same shape as DOMExceptions?
  • KN: definitely V1, but not sure we'll do anything about it. If we do put it in, has to be done by then.
• #1772 - allow RW storage on selected texture formats
  • DM: there was idea - can allow RW textures on some formats in base API, then decided we couldn't do it. If we do allow it, it'll be a feature.
  • CW: Chromium volunteered to collect some stats to see how much coverage of this feature had on macOS
  • JG: think post-V1.
  • MM: agree.
  • JG: if you want this, it's fine - just gather the telemetry and propose a spec edit.
  • DM: may be one of the most highly requested features from ISVs.
• #1573 - rich math rendering in the spec
  • KN: spec issue. Not V1.
  • CW: candidate recommendation or not?
  • MM: no.
  • CW: post-V1 then.
• #1548 - toDataURL behavior for GPUCanvasContext.
  • JG: needed for v1.
• #1405 - pr-preview doesn't run for WGSL spec PRs
  • KN: pr-preview doesn't run, but Oguz put something else in which does.
• #794 - pipeline statistics clarifications.
  • CW: can we remove these stats from V1?
  • MM: we removed timestamps. Did that also remove pipeline stats?
  • CW: we didn't land the timestamp removal yet.
  • KN: think we should remove these both from V1, move to separate document.
  • CW: for-V1: move this extension to a separate doc. Will make new issue to track it.
• #556 - frame latency in WebGPU
  • CW: guarantees on the number of frames it takes for JS draw command to get to the screen.
  • MM: doesn't affect the API.
  • KR: it can - see the WebGL desynchronized attribute.
  • KN: we can add this later.
  • JG: I vote post-V1. An add-on. Normal path would be to do what we did previously.
  • MM: if there's an opt-in mechanism people can enable it via an extension.
  • JG: have problem phrasing this as guaranteed latency. Can't guarantee that.
  • CW: since V1 has same semantic as base WebGL, this goes post-V1. Not breaking change. We'll write post-V1 features based on what people need.
• CW: time box reached! Making good progress.

Add defaults for GPUTextureSampleType in the default pipeline layout #2078

• AE: texture 2D F32 in WGSL doesn't say whether it's a filterable or non-filterable float. getBGL or no layout on pipeline creation - impl needs to pick. I made a PR suggesting a type of static analysis that's cheap - impl has to do it anyway. Proposal - if you just use it for textureLoad, you'll get unfilterable float because we don't need to filter it, ever. textureSample - we'll guess you want filtering. Will work on everything except e.g. RGBA32F or one of the other float formats.
• AE: think this is the most compatible.
• JG: think this is what we have to do. The complexity in terms of "spooky errors at a distance" is concerning.
• MM: expect at some point we'll want to link together a bunch of shader modules. The more of these static analyses we do - will have to be promoted to boundaries of shader modules. Has to be part of API function signatures. That's the downside. Larger, more complex function signatures.
• KN: analysis can only be done during pipeline creation time. Already have all the shader modules.
• DM: Austin said, we already have to do this analysis. Nothing extra.
• CW: need to know if texture binding point in the shader's used with a filterable sampler. Need to export (texture,sampler) pairs in the shader already.
• JG: my concern - someone changes some shader in their shader generation tree, and now a couple of pipelines no longer match.
• KN: we just changed the rules for implicit getBGL so you can only use them with the pipeline they came from.
• AE: incompatibility needed by that - harder to shoot yourself in the foot. Harder for impl to choose filterable / unfilterable unless we add that to the shading language spec.
• MM: why didn't you just pick one? E.g. use explicit bind group layouts if you want this feature?
• AE: also an option. Could say always filterable / unfilterable. Less compatible. Can make it work for nearly all cases with the analysis I proposed, except if you sample from unfilterable float format.
• KN: makes implicit BGLs more compatible with more use cases by taking advantage of analysis we're already doing.
• JG: one drive here - ported content, wants to use default layout for their existing shaders. In other languages they ported from, didn't have to worry about this - just use layout from the rest of the program.
• JG: I'm convinced, FWIW.
• CW: think there's mostly consensus. MM you made a good point about shader module linking. Since we already have to do that, not much worse.
• MM: resources are globals. If you had a module that used (texture,sampler) - has to be declared in that module. Module-local analysis. Problem only happens when you pass resources between modules. Maybe not such a big deal. Hopefully rare.
• CW: hope also soon after V1 we'll have an optional feature that all float texture types are filterable, and this restriction doesn't exist anymore. It's only for limited hardware.
• CW: think we have consensus, let's move on.

texture_2d_depth for loading depth values might be unnecessary? #2094

• CW: Q about using depth sampling (without comparison) for depth textures.
• MM: no updates here. I don't have further information I can provide.
• CW: happy to delay this.
• MM: we are in the middle of company-internal conversations, FYI. There is progress.
• CW: agenda for next week?
• MM: probably not.

Shader-visible entities occupying multiple locations #1733

• DM: wanted us to have good understanding of how to handle. Made decision on external textures. If we use the same decision for other things we might want - what are the consequences?
• DM: arrays for example are pretty viable to pass between stages. Would want to allow that at some point.
• KN: from author perspective - you see external texture as a single thing. BUt you interact with multiple elements of the arrays.
• DM: you interact with the array, not sub-bindings of it.
• KN: yes, but inside, you can index into it and get separate bindings.
• DM: whether you can get separate bindings is another discussion.
• KN: I don't mean binding them separately. External texture's an encapsulated thing. Array of resources looks like an array in the shader.
• DM: I'm talking about array of values passed between shader stages. Inside, it's just one thing - a value of N items.
• MM: what are the proposals / possible outcomes?
• DM: maybe we decide we should allocate e.g. 5 contiguous locations for the array elements. Explicit. You know at shader module creation time which locations are used for what.
• DM: other option: always implicit. Impls can't reason about locations at shader module creation time.
• MM: third option - treat external textures and arrays of textures differently. External textures = 1 WebGPU bindings. Arrays of textures = N WebGPU bindings.
• KN: I support that - they should be different.
• CW: external texture - you get GPUExternalTexture, can never decompose it. When you have array of textures, passed as bindings (not possible today in WebGPU), can access them individually - can ensure they all have their own location.
• CW: texture stuff - not done in Vulkan. Vulkan has separate dimensions for binding ID and array stuff.
• KN: in OpenGL it does take multiple locations. But OES_texture_external only takes one. Impl's opaque.
• KR: think the spec does say it might take up multiple uniforms.
• MM: mental model - external texture I consider a struct, and structs should be able to reorder them - but array of textures is an array, and you can't reorder elements there. Trying to provide add'l context for having different policies.
• DM: sounds reasonable. Suggest keeping as tracking issue, don't block anything on it.
• CW: sounds good,
• MM: third bullet point - can I have a vertex attribute of 1000 floats?
• CW: that's be 1000.
• JG: yes. In GLSL, can declare array - but the subsequent vectors get an element (location?) assigned, as long as they have static use.
• CW: let's say things are OK for now but keep as investigation.
• MM: same question but for intra-shader arrays? If I output 1000 values to next stage I get multiple locations?
• DM: we don't have arrays there yet - no policy deffined.
• CW: for both - have to use scalars, or vectors up to 4. WGSL doesn't support more complex yet.

(stretch) Should depth-stencil render attachments require views to have aspect = "all" for combined depth-stencil formats? #2062 (@kvark's comment with RenderBundle proposal)

• CW: first - offline, ppl agreed this is a good limitation. Just landed.
• CW: new discussion/proposal from DM - how does this change RenderBundleDescriptors?
• DM: agreed on that change because it's safe and can be extended later. Austin's or Kai's concern - flags on RBD not the best right now. Weird to specify either when you don't have depth/stencil component at all. Changing RBD so you can default them to unused would make API better. Also resolve concern about not requiring "all" in the aspects, and only validating aspects based on what's selected. If you have depth/stencil and only look at depth side - will only be validated as if it only had depth. Think it's easy, and with this RenderBundle change it becomes clear.
• CW; not sure what we have in the RBD but being able to distinguish between them is better.
• DM: have 2 bools now.
• KN: and depth/stencil component, which is optional, so we know whether it's present or not.
• DM: awkward situation- depth-only attachment, but read-only stencil, either true/false - what happens if you don't have stencil?
• KN: you still have depth/stencil format. Can have depth fomat but define stencil readability. Don't we still need the depth/stencil format in the RBD?
• CW: we need it for pipeline compatibility with attachments. "unused" = no format there, or having format that doesn't have either depth or stencil.
• DM: or your format has stencil but your view that you started the pass with isn't using it.
• KN: thought we decided we couldn't do that.
• DM: if we have this change in the RBD we can validate more flexibly.
• KN: isn't the change we just landed - depth/stencil view has to reference all aspects?
• AE: yes. In Vk/D3D12, can't attach just one aspect. But we can validate that you neither read from nor write to the aspect.
• MM: if you have DS texture - validation we just added says, you can't access the stencil component in Metal? Without binding just the stencil aspect - if you bind the depth-stencil texture - the stencil aspect's invisible. DS textures are now fairly useless on Metal. Think it's an argument for what Austin just said - allow either one. Think we should select both Austin's options (1) and (2). If unobservable whether both aspects are present - it's fine, works in every API. If it is observable - aspects have to be "all".
• CW: it is observable in D3D12/Vk because pipeline's DS format must exactly match the render pass's. If you say, this one's depth24 and you have D24S8 and try to use it with these pipelines - doesn't work in D3D12/Vk.
• KN: think this would only allow ergonomic improvements where you can use views of DS textures rather than having to make copies for render passes. But don't think it enables anything - only whether you can reuse texture view, or have to make another one. Unless there's a way where we can have the formats not match. Like casting between D24S8 and D24X8. But don't think we can do that with the rules we have.
• DM: MM's concern - if you want stencil-only view - previously create texture view with stencil component, and then uint8 binding - but now with DS components have to select all.
• AE: this is for renderpasses, not bind groups. Can still have stencil-only in bind groups.
• CW: it's renderpass validation - any use for DS attachment must span all aspects of underlying texture.
• CW: from my understanding - no challenge to the change that was landed. But not clear what to do with RBD changes.
• KN: MM said something about the change we just landed being unimplementable on Metal?
• MM: no, I had same confusion DM had.
• CW: let's promote DM's comment to a separate issue. DM can you do that? Then we can talk more about it at a later meeting.
• DM: will do. Use case was: you have a library, it gets a view and a format, and it does something with stencil. (Renderpass filling stencil, then sample with it.) Won't work as-is - need different views for binding/rendering if it's a DS texture. But if we adjust the validation a little bit, validation becomes more orthogonal.
• MM: is what you said regarding bundles?
• DM: regardless of bundles.
• MM: why can't htis work today?
• DM: rendering just to stencil, and using i t- need 2 diff views. View you render into has to have all aspects.
• MM: has to be in different passes though. One has output; the other binds stencil view of that buffer as a binding.
• DM: used in a different place - different pass, of course.
• MM: what's problem of 1 pass having DS texture, then have view of DS aspect, and use it as shader resource in second pass?
• CW: suppose you're middleware - do something with depth thing. Contact shadows, etc. Want depth-only view for sampling, and will want all-aspect view to be able to do depth test. You're middleware, don't care if it's array level 3, mip level 4, etc. Want "this mip level, this array layer", etc. - we specify everything together. Need 1 texture view with all aspects, and one depth-only view for bind group.
• CW: I understand the rationale. A bit rare. A valid potential usage that would be made a bit worse.
• CW: problem - we bundle array layer mip, etc. with the texture view - and so you need 2 different texture views for the same thing.
• KN: would be nice to make this work. But we don't need to make it work for V1 do we?
• DM: no. But we should probably do the RBD change for V1.
• KN: agree, we should discuss, let's file new issue.
• CW: can discuss next week, but that agenda's pretty full.
• KN: this is 2 issues, the one DM filed, and loosening the validation.

(stretch) Consider making ShaderModule compilation errors special #2119

Agenda for next meeting

• CW: let's skip first APAC one of next month since we're having 2 APAC meetings almost back-to-back. Please add agenda items. It's already pretty full.