Skip to content

Minutes 2021 08 09

Corentin Wallez edited this page Aug 16, 2021 · 1 revision

GPU Web 2021-08-09

Chair: Jeff

Scribe: Ken

Location: Google Meet

Tentative agenda


  • Apple
    • Myles C. Maxfield
  • Google
    • Austin Eng
    • Brandon Jones
    • Gregg Tavares
    • Kai Ninomiya
    • Ken Russell
    • Shrek Shao
  • Microsoft
    • Damyan Pepper
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert
  • Francois Guthmann
  • Michael Shannon
  • Mehmet Oguz Derin
  • Rick Battagline

CTS update


  • Chrome's Origin Trial is branching this week and we need to discuss fragment output attachment today. Would be nice to come to consensus if possible, otherwise we'll just implement something for now.
  • SS: All backends are happy with vec4 frag outputs, outputting into a narrower (e.g. r8) texture.
  • SS: fewer channels: Metal not happy about it
  • SS: two options:
    • State in the spec that component count of the fragment color output should be equal or bigger than the channel count of the colorState.format. The extra components are discarded. Otherwise there would be a validation error.
    • Do a transform of the user-input WGSL shader in our implementations to make sure the output is always expanded to vec4<T>, without validating the componentCount. (when blending is not enabled, still need validation with blending and src-alpha is read)
  • DM: would have to validate slightly differently. Don't validate against number of components the target texture has. Target texture might have alpha, have to validate …
  • KN: have to have vec4 regardless of blending state.
  • KN:couple validation options:
      1. validate everything as vec4. Most extreme.
      1. Validate as vec4 if blending's turned on.
      1. Validate as vec4 if blending mode would read alpha channel.
  • Think we should validate based on the actual blend mode. If blending uses alpha channel require the alpha channel, otherwise do it based on the output format. Should be safe according to readings of spec.
  • DM: I think we should do that.
  • KR: concerns about BGRX textures?
  • KN: we don't have any of those yet. Unlikely to draw from RGBA to RG.
  • KN: since backend APIs all dislike this, good indication for WebGPU to dislike it too.
  • MM: we already have a rule for if you have 3 renderbuffers attached but only write to 2, do you remember the policy?
  • KN: no but I don't think this should be symmetric with that. This is different. This is about the alpha channel within one output, and in the other case there's no crosstalk between the attachments.
  • KN: you either are or aren't providing a value for the attachment. Here some of the values might not be used depending on the attachment & blending state. We can do the more precise thing of seeing whether the (value's?) used or not.
  • MM: if we have validation now we can change it in the future, not vice versa. Could pad the outputs later but not change the validation later.
  • KN: right. Still 3 options for how we do the validation. Option (3) wouldn't let us make the validation less precise later.
  • MM: at the point of validation we already have the shader and all the blending modes. If we have all the info, no reason to make it less precise.
  • KN: and it's pretty straightforward.
  • JG: sounds like we have consensus (precise construction). Move forward with it?
  • MM: and if they provide more channels that's OK?
  • KN: yes.
  • (Consensus reached!)
  • JG: thanks for including approximations of availability.
  • MS: allows what's changed in a render bundle. Addresses some issues Babylon.js folks brought up earlier too.
  • DM: will Babylon require this feature now?
  • MS: don't know, doubt it. At the time, firstInstance was core. Removed 3-4 weeks ago due to 36% of Android devices not supporting it.
  • DM: concern that it'll be exposed on host devices and that's where people will test it.
  • BJ: the fact that it's behind a feature means that people should test both code paths. Better to have it behind a feature like this, rather than just present.
  • MM: how much farther can we go? New JS features are added all the time.
  • DM: the fact that it's available almost everywhere makes it more dangerous. Look harder into making it core? We don't know the 36% number - that's just the number of reports. First question - are all the Android devices supporting Vulkan going to run WebGPU? We require some things on top of base Vulkan - like the SPIR-V storage class. If that 36% is the number of devices we're not planning to run on anyway…
  • Discussion about how precise the 36% number is, and what fraction of those devices we aim to ship WebGPU on.
  • MM: if we only expected to target 50% of Android devices, this 36% (depending on whether falling inside that 50%) would be significant. But aren't we aiming to target 90% of Android devices?
  • KN: Android devices with Vulkan = 66%.
  • MM: how many of those are we targeting for WebGPU?
  • KN: we don't know.
  • DM: we also hope to ship WebGPU in some form on devices that only have GLES 3.1.
  • MM: if you put this in core you wouldn't know whether you have to fall back to GLES or not.
  • DM: Vk would tell us up front that you don't have IndirectFirstInstance.
  • KN: I suspect this is big enough that we don't want to drop it into the compat bucket.
  • MS: storage buffer is supported on 80% of Android / Vulkan devices.
  • MM: so we expect to run WebGPU on 80% of those 66% devices. Less than I thought - assumed 90-95%.
  • DM: sounds like we want to land this as a feature and consider promoting to core later.
  • KN: we really want to gather proper metrics about Android devices, ideally before we ship on Android.
  • MM: will you publish your findings?
  • KN: ideally.
  • DM: small note: can pick backend based on whether user requests this feature. This is the device request, and we already have an adapter at that point.
  • JG: you could choose to.
  • MM: layering violation.
  • JG: not even sure about that.
  • BJ: presumably spinning up GL and Vulkan on same adapter. Legit but not sure we'll go through the trouble of doing so.
  • KN: don't think we'll automatically fall back to GL - some things we won't be able to support there.
  • JG: alternative is to always fall back and be slow - worse position for apps that don't need this. That's a lot of apps.
  • MM: our position on this is that OpenGL should not affect the design of the WebGPU API.
  • JG: you are heard and it does not.
  • MM: if the explanation for a feature request is that we need it for OpenGL we'll have some thoughts about that.
  • MS: think firstInstance doesn't work in OpenGL anyways, but that was the impl I was using.
  • KN: this is indirect.
  • MS: think it doesn't work correctly there.
  • JG: that's for us to investigate.
  • MM: are we resolved?
  • JG: think so.
  • (Consensus - add this as a feature.)
  • JG: last meeting, had resolution to split this into 2. Now it is (#2022 is the other part).
  • JG: mostly-orthogonal thing to the other one, but not entirely.
  • JG: this is an optional feature.
  • MM: one of the requirements for this - to impl this in Metal we'll have to use a compute shader to transcode these buffers to use indirect command buffers. Since we have to do that in CS, have to do before the renderpass. Requirement that the buffers can't be generated in the renderpass. Same requirement as for single DrawIndirect.
  • DM: i.e. renderpass doesn't use them as storage writable usage? It can't - that would be usage conflict violation.
  • KN: would mean - single operation, i.e. the renderpass - would be both writing and reading. Not allowed.
  • MM: don't know about the mechanism - as long as we can impl with CS that runs before the renderpass. When we record the RP, see there's a command that's an indirect call, so inject another cmdbuf right before that one's submitted. Not sure it is the same requirement as single-call DrawIndirect.
  • KN: can't do that unless you split the command buffer at beginning of RP, which we can't do.
  • MM: thought it was already possible to implement this for single DrawIndirect.
  • KN: can't hoist the check before the entire command buffer. Boundaries between cmdbufs don't have special semantics.
  • MM: if that's true then either we have to split cmdbufs at RP boundaries - thumbs down - or ...
  • KN: or record RP after it's completed.
  • MM: also thumbs down.
  • KN: we don't record RP until after it's ended because we don't record the cmdbuf until it's ended. So I think splitting is OK.
  • JG: you can finish recording ...
  • MM: discussion of what's done and when cmdbufs are inserted.
  • KN: orthogonal to this issue though.
  • MM: I'll file the issue about how to inject this cmdbuf for all DrawIndirect calls.
  • MM: say we wanted full GPU generated commands. Would that be distinct feature, sibling to this one?
  • KN: definitely a totally distinct feature. MultiDrawIndirect doesn't have command IDs, just a buffer full of draw call data. Data driven. Separate feature.
  • MM: little unfortunate to have one feature that's strict superset.
  • JG: do you think we'll run into this problem?
  • MM: yes. Someone at some point will propose device generated commands / indirect command buffers. Not a blocker. Asking just because our eyes have to be open to the future.
  • KN: think it'll have wider reach than that hypothetical future extension, so don't see a problem with having both.
  • JG: any problems with this particular PR? Noted some problems we already have, but think we can land this feature, or do people want time to think?
  • MM: does D3D support this?
  • MS: yes. This is fully supported on D3D, no extensions required.
  • MM: data format's the same?
  • MS: less flexible than Vulkan but can be made compatible. Vk allows a stride between the blocks, D3D doesn't.
  • JG: resolved to merge when we can - after the other one's landed and merge conflicts resolved.
  • MM: this one doesn't have a stride?
  • MS: correct, to be compatible with D3D.
  • DM: may need to wait until Corentin's back.
  • JG: table this for now.
  • KR: We want to avoid doing conversion operations in “uploads” to other rendering contexts.
    • KN: Suggesting texImage2D et al from WebGPU canvas sources ignore the UNPACK_PREMULTIPLY_ALPHA_WEBGL setting?
    • KR: Possibly
  • DM: You say compositeMode should not affect what you read, but the most efficient way to implement it on may platforms is to fill opaque buffers’ alpha with 1.0.
  • KN: in the API as written, not possible to implement "opaque" that way. Maybe this another thing blocked on figuring that out.
  • DM: we shouldn't block the optimal path from happening in the future.
  • KN: happy to call this issue blocked on that issue.

Agenda for next meeting

  • JG: please put any other agenda items for the next meeting here!
  • JG: had some interest by at least one member to have a communications channel for southern APAC members.
    • MM: CSS once a month has their call in California's evening time, to align with Asia.
    • JG: could consider doing that.
  • CW: won't be there next week, but still discussion between empty and "null" bind group layout, and how you unbind stuff from the pipeline? will be a pain point.
    • wart that we need to fix sooner rather than later.
    • MM: we discussed that 4 years ago if I remember correctly. But no idea if the consensus we reached will apply to today's spec.
    • CW: we didn't have a spec to record the decision in.
    • DM: fix can be 1 line in the spec. BGL is the same, etc. Please do fix it. We want it too.
    • CW: maybe I'll make a PR but won't be there to defend it.
    • MM: there are other design options. "unbind" this bind group from this slot.
Clone this wiki locally