Skip to content

GPU Web 2024 07 17

Jump to bottom
Corentin Wallez edited this page Jul 23, 2024 · 2 revisions

GPU Web WG 2024-07-17 Pacific-time

Chair: KG

Scribe: KR

Location: Google Meet

Tentative agenda

  • Administrivia
  • CTS Update
  • Push constant proposal #4612
  • createTexture does not validate viewFormats against usage #4426
  • The bgra8unorm-storage feature should most likely only enable write-only access #4377
  • maxInterStageShaderComponents seems to overlap with maxInterStageShaderVariables #4688
  • Allow all vertex input attributes to be considered OOB if at least one is (in the "process vertices" algorithm) #4668
  • (stretch) Hardware feature levels (and compat) #4656
  • Agenda for next meeting

Attendance

  • Apple
    • Mike Wyrzykowski
    • Myles C. Maxfield
  • Google
    • Brandon Jones
    • Gregg Tavares
    • Kai Ninomiya
    • Ken Russell
  • Intel
    • Jiawei Shao
    • Shaobo Yan
    • Zhaoming Jiang
  • Microsoft
    • Rafael Cintron
  • Mozilla
    • Jim Blandy
    • Kelsey Gilbert
  • Xiaoshen X

Administrivia

  • Should the WebGPU WG attend TPAC?
    • MW: +1
    • KR: For myself and some others, would prefer to keep with regular meetings plus a F2F for us. We don’t think we have enough to talk about with other groups that it would be productive.
    • KN: thought we told organizers that we weren't meeting at TPAC? Was there a deadline?
    • KG: not sure. Thought that deadline had passed, and that Corentin had told the organizers.
    • Let's say we aren't attending TPAC as a group. But if you're there, coordinate with others :)
    • MW and RC will be at TPAC
  • WebGPU F2F?
    • Maybe in the Mon Oct 28 – Wed Oct 30 window?
    • Bay Area location?
    • Note: Halloween (Thu Oct 31)
    • KG: Jim says we / Mozilla should be in a good enough place by then to talk about future stuff (still working on shipping right now)
    • RC: open to this F2F
    • KG: let's see if 2 full days in this time window can work for folks
    • MW: I could attend these dates
    • MM: can probably attend, at least if in bay area
    • KG: those dates work
    • Intel folks?
    • SY: would need to discuss. Maybe dial in remotely.
    • KG: let's discuss next meeting. Will send an email.
    • RC: BlinkOn's at the beginning of October. Could we make the F2F overlap it or be near it?
    • KG: October 9's Canadian Thanksgiving day. 14th is Indigenous People's Day in the US. But we can consider it.
    • RC: Here is the BlinkOn 2024 announcement. [blink-dev] Save the date for BlinkOn 19!

CTS Update

  • KN: Gregg working on first/either provoking vertex convention. It's working in Chrome. Should be more or less happy now.
  • GT: still working on texture builtins tests. A couple landed, more coming.
  • KN: CTS for depthBias was changed.

Push constant proposal #4612

  • https://github.com/gpuweb/gpuweb/blob/main/proposals/push-constants.md
  • This has been merged into the proposals/ directory. 3 open questions written in that doc.
  • SY: discussion of per-stage push constants. All 3 APIs define immediate data with visibility per-stage. In our proposal, to simplify implementation, the immediate data is visible to all stages. Question is whether we should align with the native APIs - or keep implementation simpler.
    • JB: concern Teo brought up was having a combined set of push constants. All stages have to share the same capacity then, and the capacity's pretty low. If we can design the API to be upward-compatible, and insert an alternative system later with per-stage push constants, would be ideal.
    • KN: it differs between backends whether you actually share the space or not. In D3D these'd go into the root signature, so I assume you wouldn't lose space to have visibility at all stages. Not sure about all backends.
    • JB: if the push constants come out of shared space anyway then yes, visibility would only affect visibility and not the actual amount of immediate memory consumed.
    • KG: no conclusive answer yet - that's fine.
    • MM: DirectX doesn't split the parameter space (for root constants) - just checked.
    • KG: would an investigation be helpful?
    • SY: for D3D, defining different visibility for vertex/fragment - not sure it'd work
    • JB: I can check for Vulkan. If all platforms unify the namespace, that answers the question.
  • SY: should push constants affect bindgroup compatibility? If you have comfortable immediate range - user can have immediate data values. No need to make extra calls like "setImmediateData". Concern - have some impl details also using immediate data internally. In impl, might need to do some copy / internal setting. Hesitant to expose these concepts to WebGPU. Always call setImmediateData when calling setPipeline?
    • KG: initially - would say they aren't compatible. In the future, could make them more compatible.
    • SY: agree.
    • KN: we have the immediate byte range for push constants in the pipeline layout (?). Two pipeline layouts the same, both have 8 bytes immediate data, then they're incompatible with each other?
    • SY: not incompatible with each other, but incompatible in immediate data range.
    • KG: think we should try to maintain - have a pipeline layout descriptor that's teh same between two pipelines - they should be compatible. Shouldn't make them incompatible because you changed the immediate data byte size.
    • KN: ok. That's what the proposal says. Compatible for immediate data if they're the same size.
  • SY: the third issue is a question. Each entry point should only use a single immediate data. Should this restriction be extended?
  • KG: sounds difficult to expand this and know the order they happen in.
  • KN: if we expanded it we'd put an ID on it and you'd specify the ID when setting immediate bytes.
  • KG: sounds nicer to say 1 for now.
  • KN: does make the proposal simpler.
  • KN: Jasper was asking, why this restriction. Seemed artificial, compared to what's available in the backends.
  • MM: any precedent to allowing only 1 of anything in WebGPU?
  • KN: sort of. Only 2 attachments if using dual-source blending. Generally, don't think so.
  • MM: seems artificial to me too. From author's perspective: a shame if we have a great feature but you only get one.
  • KN: it's still limited to 64 bytes by default.
  • MM: could imagine someone wanting 2 integers.
  • KG: do it with structs. Right now, have 1 contiguous range of bytes. This is the time while this is in the proposals stage to explore different ways of doing this.

createTexture does not validate viewFormats against usage #4426

  • KN: unfortunately Teo can't make this concall today. Revisiting this because I didn't understand the issue fully when discussing it. At the time I thought there was a problem with the spec. Not the case - the spec's fine. Discussing a breaking change to it. Wanted to do this because - want usages for views anyway. Not sure about this conclusion. Not sure what the value is in being able to restrict usages for a view. Currently, there's validation at some point (createBindGruopLayout), can't use storage with a format that doesn't support it. Can't bind the view; so OK for impls to elide storage usage when creating the view. Breaking change - if we want to subset usages, this automatic subsetting's surprising. Predicated on wanting to add usages to the view. Should be motivated by some idea that this is useful for perf. Not useful for anything else.
  • KG: clarity's one place where it'd be useful. E.g. this view can't be used with STORAGE even though the texture said it could be. The silent allowing of these feels opposite of the explicit design.
  • GT: I worry that if I need to remove STORAGE touse the texture, why am I not required to remove - like, having to remove TEXTURE_BINDING when want to use it as a render target? Have to remove a lot of uses. Right now, we specify all the uses that we might want to use.
  • MM: neither Metal or Vulkan have this feature we're describing. Does DirectX?
  • KN: Vulkan does have this feature.
  • MM: ImageView, creation function doesn't have this feature.
  • KN: it works by VkImageViewUsageCreateInfo:
  • MM: ok. Does it make things faster?
  • KN: I'd like to know that too. 🙂
  • MM: does DX have this?
  • KN: doesn't have texture views the same way Vk and Metal do.
  • MM: that makes me think this feature isn't worth the WebGPU WG's time.
  • KG: we discussed this previously, decided we should add it.
  • KN: Teo points out, we'd be able to look at the usage and decide whether to make SRV, UAV, RTV/DSV in D3D. So it can be used there as well.
  • KG: continue discussion with Teo next time.

The bgra8unorm-storage feature should most likely only enable write-only access #4377

  • KN: resolved this in API group; Alan had feedback. Thought read-only would be polyfilled with texture fetch and swizzle. Have to change texture fields on API side too. We didn't consider that approach. Maybe could do what we previously resolved on, and try to relax it later? Could use read-only with BGRA storage. Impl's not too trivial. Shader generation work, inject texture binding usage when texture's created, etc.
  • KG: so is the impl complexity worth it?
  • JB: Moz wouldn't be able to look at this for quite some time.
  • KN: if that's the case then we don't want the spec to say we have to do it. So we should land the spec change and remove the ability to do read-only with bgra.
  • JB: file bug for later to remove the restriction.
  • KG: can do that. For M2. Resolved: restrict for now, file follow-on issue.

maxInterStageShaderComponents seems to overlap with maxInterStageShaderVariables #4688

  • KG: Kai's proposal to deprecate but not have it be a breaking change.
  • KN: yes. I'm convinced we should figure out how to do this. A little trickier than some other deprecations. Maybe nothing else we need to discuss.
  • MW: could we maintain this, mark it deprecated, log a warning to the console, and also automatically align these variables? Seems quite uncommon that you'd want to raise one and not the other (end up failing validation in one case or the other). Along the lines of Kai's suggestion.
  • KN: if we keep it forever then we should go through all that. Don't think we do. So, up to Chrome to figure out how to deprecate & remove from our impl. Would do some of those steps. Wouldn't need to do the auto-upgrading.
  • KG: which one are we keeping?
  • KN: maxInterStageShaderVariables.
  • MW: thumbs up
  • KG: we'll await a PR proposal.
  • KN: yes. To facilitate us deprecating/removing this, might want to change the way required limits work so that it's OK for you to pass "undefined" for an unknown key. That way we can raise a deprecation warning. And then remove it …
  • KG: might want to treat this differently. Have this one - it's OK for just this one.
  • KN: thinking about this too.
  • MM: that's what I suggested last week.
  • KN: is this something we'd put in the spec?
  • MM: don't know. Reason I hesitate is that there's only one browser currently shipping WebGPU. Maybe it should just be a browser-specific quirk.
  • KN: had another motivation for supporting undefined in the required limits.

Allow all vertex input attributes to be considered OOB if at least one is (in the "process vertices" algorithm) #4668

  • MM: seems like a no-brainer to me
  • MW: thumbs up
  • KG: resolved. Awaiting PR.

(stretch) Hardware feature levels (and compat) #4656

  • KG: move this to M1 (instead of M0).
  • KG: were planning to discuss whether Compat would be a feature level 0, 0.9, etc. Or if we're looking forward at future feature levels, and Compat being its own thing.
  • KG: also probably useful - do we have a strawman yet for feature level 2?
  • KN: don't think so.
  • KG: think that'd help orient us. But, we can decide whether to integrate Compat with feature levels.
  • KN: benefit of integrating the two - you wouldn't have to requestAdapter twice to support both Core and Compat in an app. Maybe not a huge deal. But later on when there are more feature levels, and you have a different mechanism to check for the two - or rather, Compat, Core, and in Core you check for individual features to upgrade your rendering - 2 different mechanisms.
  • KN: benefit of other way, with a boolean - think we can remove the boolean from impls later. It's just the value of an enum we'd preserve forever - not a big deal. Has defined behavior if you're ignoring it. And all impls need to know the name of the enum.
  • MW: I left comments in this issue - Apple's in favor of the proposal, so adoptees wouldn't have to create 2 devices if Compat isn't supported.
  • KG: that does sound useful. One thing I'm concerned about - inherent difference is that Compat's taking things away. Adding language to the spec to restrict things when you have Compat. As a feature level, going back to Myles' concern a while back - is Compat then not actually the base feature level for the spec? Think we don't want to structure the spec that Compat's the bones and then we add Core on it. But these aren't incompatible in an API that puts them together. In sum, probably fine to come up with a feature levels idea, but need proposals.
  • MM: 2 different things - shape of the API (enum vs. separate bool) and behavior when app requests one but hardware supports a different one (auto-upgrade or fail). Different questions.
  • KN: proposal I wrote should answer these questions. It's fully fleshed out. That specific question, there'd be no auto-upgrade because feature levels are additive. Could still provide the previous feature level - browser would enforce validation - until the impl wants to remove that FL entirely, at which point they'd be allowed to auto-upgrade it, and stop doing manual validation.
  • MW: thumbs up
  • MM: web app's perspective, they request Compat mode, they get validated according to Compat's rules, until browser rips that code out? Then they wouldn't be validated against?
  • KN: yes. That's what would happen for Safari, assuming they don't implement Compat.
  • MW: thumbs up
  • KN; which is the same as the other proposal. You ask for Compat mode, and if the browser ignores that, it gives you a regular Core device. In the design from the beginning, so Safari doesn't need to implement Compat.
  • KG: sounds like Kai has a proposal which satisfies the WG, so it sounds like it's ready for a PR.
  • KN: think the proposal's going to be more readable than a PR, so if you have feedback, please read proposal (A).
  • KG: absent opposition, I think we're ready for a PR.

Agenda for next meeting

  • KG: when should we meet? Took the whole hour this time. Not sure how much to discuss, and this was an APAC timed meeting.
  • KG: tentatively, plan on Atlantic time meeting next week.
  • KN: would prefer to have a meeting next week. After that I won’t be able to attend until Aug 28.
    • Also, 2 weeks from now (Jul 31) is during SIGGRAPH.
  • KG: please add agenda items here!
    • createTexture does not validate viewFormats against usage #4426
    • [editorial] Consider if there's a much better name for "image copies" #4573 (comment)
    • (has draft PR) Hardware feature levels (and compat) #4656
    • Compatibility Mode: Support OpenGLES devices with zero SSBOs and image uniforms in vertex, fragment stages #4721
    • (Ken) WebGPU benchmark(s) in MotionMark?
    • On device loss, should mapAsync throw AbortError instead of OperationError? #4774
    • (discuss/approve small details of) Add texture-compression-bc-sliced-3d #4763
Clone this wiki locally