Skip to content

GPU Web 2024 04 10

Jump to bottom
Corentin Wallez edited this page May 7, 2024 · 1 revision

GPU Web CG 2024-04-10 Atlantic-time

Chair: Corentin

Scribe: Ken

Location: Google Meet

Tentative agenda

  • Administrivia
  • CTS Update
  • “Tacit Resolution” Queue
  • Add support for 3D compressed textures. #3183
  • Compatibility mode: provoking vertex differs between OpenGL and WebGPU #4489
  • Compat: Disallow textureSampleLevel/textureSampleCompareLevel with texture_depth_2d_array #4519
  • Compat: Drop ASTC requirement in compatibility mode. #4566
  • Merging compat in the spec
  • Agenda for next meeting

Attendance

  • Apple
    • Mike Wyrzykowski
  • Google
    • Brandon Jones
    • Corentin Wallez
    • Gregg Tavares
    • Kai Ninomiya
    • Ken Russell
    • Stephen White
  • Microsoft
    • Rafael Cintron
  • Mozilla
    • Jim Blandy
    • Kelsey Gilbert
  • Nvidia
    • Anders Leino
  • Albin Bernhardsson
  • Mehmet Oguz Derin

Administrivia

  • WebGPU WG link: https://www.w3.org/2020/gpu/
  • Today's meeting will be a CG meeting rather than a WG meeting
  • We'll start doing mostly WG meetings since that's a better way to do standards, but we'll do this with more lead time. Maybe starting in May.
  • FYI François Daoust emailed the working group about living standards with Candidate Recommendations. More details - useful information.

CTS Update

  • This is the WGSL CTS. Keeps finding bugs in the compiler - great! and ambiguities in the spec.

“Tacit Resolution” Queue

  • Empty!

Add support for 3D compressed textures. #3183

  • MOD: In most of the native APIs we can use 2D compressed blocks for 3D textures. This is useful for scientific visualization. Already available in WebGL2.
    • Metal: we don't target Apple2 or Common1 (?) feature sets any more
  • CW: WebGPU - texture size has to be multiple of the block size. D3D constraint. Would carry over for 3D compressed textures using a 2D compressed texture format. But depth wouldn't have that constraint.
  • JB: Moz thinks this is a relatively straightforward addition
  • CW: this would be core
  • JB: that's fine.
  • BJ: in favor of anything that makes us not regress from WebGL. :)
  • KN: reason we didn't do this initially is there were issues with 3D texture formats like 4x4x4, didn't do the work to understand what's supported. Now we know, those aren't supported anywhere.
  • MW: think we should add compressed 3D texture support.
  • CW: OK, now just need to implement, test, add to the spec.
  • KG: PRs welcome. High-level approval.
  • KN: need to test it. M1 target?
  • CW: yes. Regression w.r.t. WebGL.
  • JB: yes.
  • CW: thanks for nice investigation, made things easy.

Compatibility mode: provoking vertex differs between OpenGL and WebGPU #4489

  • (KG: The WGSL group is handling this now. Was there something new we wanted to discuss on the API side?)
  • SW: deprecating @interpolate(flat), or not. Undecided, would like to hash it out here. Would like to consider not deprecating it.
  • KG: things not touching the API would ordinarily be discussed in WGSL group.
  • SW: ok, makes sense. I can attend WGSL meetings, modulo timing.
  • Plan to discuss this in next week's WGSL meeting.

Compat: Disallow textureSampleLevel/textureSampleCompareLevel with texture_depth_2d_array #4519

  • GT: doesn't exist in GLSL ES.
  • GT: Question that came up (really, all Compat issues affecting WGSL): shaders compile, but you'll get a pipeline creation failure later if you're in Compat mode. Advantage of doing this at shader module creation time: you get line numbers and good error messages.
  • KG: sounds like we need an issue to discuss this for Compat.
  • CW: where should this be discussed? API or WGSL side?
  • KG: touches both.
  • GT: will file issue.
  • CW: irrespective of where the error's produced - textureSampleLevel could be handled by converting it to textureGrad. Looked at that? Teo thinks it's possible.
  • JB: doesn't sound like satisfying workaround.
  • CW: think we can just validate this out.
  • SW: can presumably use the workaround for level 0.
  • KN: why does the level need to be 0?
  • JB: textureGrad only provides the same info if the level's 0.
  • KN: thought you could just pass a value into textureGrad to select the right level. Computes an LOD. If you pass one pixel for the grad it should give you level 0; half a pixel, level 1; etc.
  • CW: can tentatively say we validate this out, and ask for more clarification on the issue.
  • KN: can enable it later.

Compat: Drop ASTC requirement in compatibility mode. #4566

  • SW: ASTC isn't core until GLES 3.2. Propose we validate this out. In Compat, required only to have BC or ETC2.
  • CW: Teo says on Android, essentially all devices support ASTC in GL. Other devices we care about for Compat that don't support BC?
  • KG: it's unfortunate to have ETC2 as the only available option.
  • KR: Android graphics dashboards still have a lot of GLES 3.1 devices. Do they have the ASTC extension?
  • KN: yes, Teo looked at widespread extension support of the ASTC extension.
  • CW: Need to look at the data on ChromeOS but at least for Android we don't need to remove ASTC.
  • CW: Action: check with ChromeOS folks. If there's widespread ASTC support, we'll close this issue.

Merging compat in the spec

  • CW: in discussions about CR, sounds like we want to stage this first in the WD version, then move to CR. Should get to CR first before merging. So, it should live in the proposals/ folder until we reach CR.
  • Agreement.
  • KN: would like to discuss the process of WD/CR at some point.
  • KG: sounds like we want more people to read François' email about living specs. TLDR: you make a CR snapshot, and make new drafts for CR. WD becomes the scratch notebook. Currently what we do in the proposals/ folder; don't think we want to merge everything from that folder into the WD.
  • KN: don't want to do it that way. Problem: every time we want to ship something to CR we have to cherry-pick changes, rather than just update the version to point to the WD instead. Cherry-picking, don't think it will work well.
  • KG: not proposing primarily cherry-picking. Rather, things we want in a new release.
  • KN: would like to not put anything into WD that we think is ready.
  • KG: agreed. That's why I think we shouldn't put all proposals into the WD.
  • CW: thinking, put standards track stuff into WD. Then snapshot into CR periodically. Fix bugs along the way.
  • Discussion. KN had specific nuance. (KN/KG/CW) on same page.

(bonus) Validate compat restrictions in shader module or pipeline creation?

  • Raise issue, need both API and WGSL to look at it.
  • Discuss in WGSL meeting since that’s where the decision was made about where to raise errors about usage of language and feature extensions
  • https://github.com/gpuweb/gpuweb/issues/4568

Agenda for next meeting

  • CW: suggest skipping next one. Agenda for this one was small, and we finished ½ hour early.
  • 2 weeks or 3 weeks? 3 weeks would be May 1.
  • CW: if we say 3 weeks I'd hope we can make progress on Compat issues offline. Provoking vertex, and where shader compilation errors happen.
  • KN: WGSL group is the one which discussed extensions, so they should discuss them.
  • CW: so, since we don't have a lot of API side stuff, let's postpone to May 1. Would be Pacific. APAC folks haven't been able to join WebGPU meetings for a while. And this will be a WG meeting. Will send email.
  • Agenda
    • 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
    • Spec allows resolveTarget to be 3d but doesn't allow selecting a depth slice #4600
    • Push constant proposal #4612
    • Add optional feature dual_source_blending #4621
    • 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
    • [editorial] Consider if there's a much better name for "image copies" #4573
    • Does an override need to be statically used by the entry point to be allowed? #4624
    • Add synchronous GPUAdapter.info #4550
    • Discussion about feature level API and Compat (no issue yet?)
Clone this wiki locally