Skip to content

GPU Web 2024 03 06

Jump to bottom
Corentin Wallez edited this page Mar 12, 2024 · 1 revision

GPU Web 2024-03-06 Pacific-time

Note that unless stated otherwise this is a GPU for the Web community group meeting and not a working group meeting.

Chair: KG

Scribe:

Location: Google Meet

Tentative agenda

  • Administrivia
  • CTS Update
  • “Tacit Resolution” Queue
  • WebGPU compat:
    • Compat: can not copy multisample textures #4468
    • Compatibility mode: provoking vertex differs between OpenGL and WebGPU #4489
    • When to merge in the spec?
  • Should we constrain the location of user input-output stage variables WGSL #1962 (PR #4503)
  • Should alphaToCoverageEnabled require a blendable format? #4506
  • HW Clip Planes support #390
  • (stretch) Clarify handling of out of range color values #4499 (issue #4239)
  • (stretch) Add extended range #4500 (issue #4239)
  • (stretch) Allow using a (float32-filterable 2d single level) texture view for an externalTexture binding. #4504
  • Agenda for next meeting

Attendance

  • Google
    • Gregg Tavares
    • Kai Ninomiya
    • Ken Russell
  • Intel
    • Hao Li
    • Jiawei Shao
    • Shaobo Yan
    • Zhaoming Jiang
  • Microsoft\Rafael Cintron
  • Mozilla
    • Kelsey Gilbert

Administrivia

CTS Update

  • KN: lots of WGSL testing ongoing. API team started helping out with WGSL tests - a lot to do, wanted to share the load among the team and make sure we have good coverage by the time Firefox and Safari want to ship.
  • KN: François contributing Shared Worker and Service Worker tests. There are very basic targeted tests and you can also optionally run any/all tests under either configuration.

“Tacit Resolution” Queue

  • Nothing this week

WebGPU compat:

  • Compat: can not copy multisample textures #4468
    • GT: wrote the shader that would be needed, but didn't connect it up. Since this is rejected, other team members thought it should stay rejected.
    • KG: can users do anything if they need this?
    • GT: yes, it's a single draw call with a single pipeline.
    • KG: OK, we can consider making things easier later but let's leave it rejected. No compute shader functionality for this?
    • GT: there is nothing in ES 3.1 for writing to multisampled textures from compute. Only in ES 3.2.
    • GT: it's already checked in to the Compat proposal and tests have been added validating out these calls.
  • Compatibility mode: provoking vertex differs between OpenGL and WebGPU #4489
    • GT: basically, think we should do nothing. In Compat, it might be first, or it might be last. If you care, figure it out. If you opt in to Compat, your code needs to be compatible with whichever way it might work.
    • KG: worry that easy to write an app not aiming for Compat, accidentally bake in that flat means provoking vertex=first, and then hope it works
    • GT: didn't find examples where people needed specifically first or last provoking vertex. Talked with Unity; they don't do anything special even though they run on different APIs with different provoking vertex conventions.
    • KN: think we should add "flat_any" as an opt-in to core and compat, and remove "flat" in compat.
    • Discussion about compatibility issues.
    • KG: think we should then deprecate "flat" and replace with "flat_first" and "flat_any"
    • GT: I'd like the minimum amount of work
    • KG: in non-Compat mode, you get "first" every time. Core WebGPU on Android, still first. Then you decide you want Compat - does it validate on my test machine?
    • …
    • KN: we'd need to support both flat_first and flat_any in core, and only flat_any in Compat. Not sure what to do with "flat".
    • KR: just remove "flat" in Compat. I'm not sure it's worth the contortions to do that. Need to add a new keyword to the shading language. Think the number of developers impacted by this will be relatively few, and not worth adding it.
    • GT: to summarize one idea:
      • "flat" means "flat_first"
      • "flat_any" is added to the shading language, supported in both Core and Compat
      • "flat" is removed in Core
    • KG: if Chrome hadn't shipped would we call it "flat_first"?
    • KN: it's not that critical that it's "flat_first". If we hadn't shipped I'd probably say "flat_any" and "flat_first".
    • KG: why not do that now? Seems like the best solution.
    • GT: can we leave "flat" meaning "flat_first"?
    • KG: if they don't type it out, they might not understand the implication.
    • GT: when you port to Compat, you'll get an error that you can't use "flat" in Compat anyway.
    • KG: could be, but people will write a lot of code that won't work in Compat. Would like it if they wrote code that worked. Encourage them to write "flat_any".
    • KN: people will have to type "compatibilityMode: true" anyway. Won't "just work". A little annoying they'll have to fix flat to flat_any in Compat. I don't think it's a huge problem. Compilation from SPIR-V, we'd probably just translate "flat" as "flat_any". Anything out there translating GLSL -> WGSL would translate to flat_any. Don't think the burden will be that big, making people type flat_any.
    • KG: feels unnecessary, when you could have documented the whole time that you needed it. I expect that in the future, most apps would want to run in Compat mode.
    • KN: how about you write down the proposal to add both flat_first and flat_any, and deprecate flat. Can discuss. I'm fine with it.
  • When to merge into the spec?

Should we constrain the location of user input-output stage variables WGSL #1962 (PR #4503)

  • JS: current algorithm in WebGPU spec doesn't align with Vulkan spec or Vulkan validation layers. Have to fix it. Unfortunately, a breaking change. Linked to Corentin's investigation.
  • Any interstage variable should assume 4 components, regardless of whether it's a scalar, 2-component vector, etc.
  • KG: the PR's approved, so think you can merge it unless there's more feedback.
  • JS: no further comments.
  • KG: will merge.

Should alphaToCoverageEnabled require a blendable format? #4506

  • KG: Metal validation being passed down to us. Should we just say it's required? Alternative is - potential workaround?
  • KN: was warning whether the warning's correct. But don't think the behavior we currently allow is valuable, so think we should add this restriction.
  • KG: Metal considers this part of the fixed-function blending hardware. That's the consideration. Need to send a PR for this.

HW Clip Planes support #390

  • JS: last WGSL meeting discussed this: widely supported, useful. Supported in WebGL as an extension. Think we should have it in WebGPU as an extension.
  • JS: small issue - HLSL style or Metal style. Think HLSL style is easier to implement in Vulkan. If Metal style, should at least have an if-statement to do a check.
  • KG: potentially have overhead if we don't optimize it. I don't like the HLSL style, but that's a WGSL style question rather than an API style question. Do we add this now? And is it an optional feature?
  • JS: yes, it'd be optional.
  • KG: think it's time to write a PR for this. Finish discussing the shape of the WGSL builtins in the WGSL meeting.
  • JS: we'll do it.
  • KG: thanks.

(stretch) Clarify handling of out of range color values #4499 (issue #4239)

  • KG: think this is what we agreed to. Will read this offline.

(stretch) Add extended range #4500 (issue #4239)

  • Depends on the previous one.

(stretch) Allow using a (float32-filterable 2d single level) texture view for an externalTexture binding. #4504

  • KG: concern that this constrains our implementation of external textures. Had some positive signals from our media team that it might be possible that all video formats are 2-plane NV12 style formats. In that case, tempting to implement this to support this. But if external textures support canvases, would want them 4-channel, 1-plane textures.
  • KN: [external texture from canvas] has been discussed, but not proven that it was needed. And it's a bunch of work to implement.
  • KG: if we had that, would be easier for us to agree to this - it wouldn't constrain us, because we'd already have the constraint.
  • KN: Corentin points out that VideoFrame can be constructed from RGBA data as well.
  • KG: would receive that as bytes.
  • KG: spooky to me - crosses concerns, hard to know it'd be sound going into the future.
  • KG: this is an area where impl experience is needed. PR welcome adding this to the draft spec. Chromium can then implement behind a flag.
  • KG: What if we could create an externalTexture from a texture-view, rather than allowing binding either an ExternalTexture or a TextureView? Just wrap a TextureView in an ExternalTexture and bind that.
  • KN: small hesitation that it sounds like it accepts GPUTexture from another GPUDevice (since it’s “external”), but this would not be allowed. Otherwise seems fine.

Agenda for next meeting

  • Next meeting - maybe next week. Might be canceled.
  • Agenda
Clone this wiki locally