Minutes 2022 12 07

GPU Web 2022-12-07

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

Chair: CW!

Scribe: KR

Location: Google Meet

Tentative agenda

• Administrivia
• CTS Update
• “Tacit Resolution” Queue
• Full burndown!!!
  • Primitive clipping at the rasterization stage is inconsistent between APIs #3638
  • Metal can only create 32 MTLCounterSampleBuffers at once? #3652
  • Passive Fingerprinting Surface #3101
  • Permissions Policy for WebGPU and for unmaskHints #3483
  • Should the API enforce that writable storage buffer bindings don't alias each other? #1842
  • WGSL: allow bgra8unorm as texel format with extension bgra8unorm_storage #3640
• (stretch) Frame presentation timing queries/control? #3634
• Agenda for next meeting

Attendance

• Apple
  • Dan Glastonbury
• Google
  • Austin Eng
  • Brandon Jones
  • Corentin Wallez
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
• Microsoft
  • Jesse Natalie
  • Rafael Cintron
• Mozilla
  • Jim Blandy
  • Kelsey Gilbert
  • Teodor Tanasoaia

Administrivia

• CW: Reminder this is a CG meeting and not WG.
  • CG IP constraints are more loosely defined than WG. If there are IP-sensitive topics, we might have to ask non-WG members to leave briefly.
• CW: Archive the WSL and SPIRV execution environment repo? Superseded by WGSL. Not deleting, just archiving.
  • KG: also, can un-archive later if we want.
  • CW: unanimous consensus, will do.
• CW+KG: Bless samples to go in the webgpu/ organization (rather than gpuweb/)
  • CW: also WIP WebGPU debugger our team recently prototyped ("spector2")
  • CW: any objections (none raised), let me know
• KG: F2F?
  • CW: last one was Seattle, early 2020
  • CW: would be ideal for us if we can minimize travel. Most members of our team are in Bay Area, so that location would be ideal, if not as desirable as Hawaii
  • CW: Maybe week of Feb 20, 2023?
  • KG: Prefer earlier but we’ll put out a Doodle poll
  • KR: would like to avoid the week of ~Feb 12
  • CW: Can Mozilla host?
  • KG: I will check.

CTS Update

• Gyuyoung (Igalia) has been adding stencil behavior tests, few more to go and some depth behavior tests, then texture sampling/filtering
• Shrek, Loko actively contributing to CTS right now, fixing validation (encoder state), spec issues marked as needing CTS updates
• CW: also efforts on builtins tests. Difficult topic. We expect writing more WGSL tests soon.

“Tacit Resolution” Queue

• begin pass: only generate error on incorrect state #3665
  • “This fixes what I think was a semi-unintentional change of createRenderPass/createComputePass validation failures, from invalidating the parent encoder, to generating validation errors.” (apologies for the unintended churn)
  • (No pushback)
  • KG: Sounds reasonable
• Clarify powerPreference may also affect the power configuration on selected GPU #3664
  • “This patch adds a clarification that the parameter powerPreference in requestAdapter() can not only be used to influence the GPU selection in a multi-GPU system, but also affect the power configuration on selected GPU.”
  • KN: can change the power governor or similar. Just non-normative note.
  • KG: sure.

Internationalization Metadata for Human-readable Messages #2780

• KN(pretyped): i18n group agreed with our proposal, so this is resolved. Moved to editorial.

createPipelineAsync() doesn't reject its promise, even if the created pipeline is invalid #3296

• KN(pretyped): Already resolved, just needs PR to land.
• CW: Web IDL was fine; there was an issue, now resolved.
• KN: I have the PR #3523 open, just need to revise and land.

Primitive clipping at the rasterization stage is inconsistent between APIs #3638

• KN(pretyped): To follow up on last week’s discussion, talked about this more with Corentin and figured out there shouldn’t be concerns about the polyfill (to clamp always) forcing implementations off the early-z fastpath. On both Vulkan (without extension) and Metal (Apple Silicon only):
  • To implement “clip:yes, clamp:yes”: Choose MTLDepthClipModeClip. Due to clipping, no depth value can be out-of-range unless the frag_depth output is used. If it is used, we inject a clamp.
  • To implement “clip:no, clamp:yes”: Choose MTLDepthClipModeClamp. The hardware does the clamp for us.
• So I think this resolves the only concern. Can resolve?
• KG: is there a choice to be made here?
• CW: not really. D3D forces the decision.
• KG: OK.

Metal can only create 32 MTLCounterSampleBuffers at once? #3652

• CW: in Chromium we say OOM when this happens. There are ways to virtualize this - eagerly serialize into buffers to free space for other queries.
• CW: our position - whatever. OOM, or you do the work yourself at the app level.
• KG: only caveat - if we made it a limit, make it 32 for V1.
• CW: not sure that works. We haven't tested, but Metal devices on Apple are per-process. So across all WebGPU devices for all tabs. Hard to rationalize.
• KG: that's more OOM category for sure.
• CW: we can also revisit this later.

Passive Fingerprinting Surface #3101

• CW(pretyped): Last time we discussed Kelsey mentioned she had a "blog post" ready to be pasted on this issue to close it.
• KG: I will try to do this this week.

Permissions Policy for WebGPU and for unmaskHints #3483

• KN: no proposal open yet. Need to figure out what the permissions will be. 0, 1, or 2 permissions? What will they be?
• KN: where we landed so far - like there to be an option for browsers to use something as limited as a software adapter by default in iframes, and a permission for getting out of that. That's all we felt strongly that we needed.
• KN: a policy like "full WebGPU". Depending on browser - gets you either out of software mode, out of the basic profile, etc.
• KN: might also want one for requestAdapterInfo. Might have a permission prompt for that, and you need a permission policy for all such prompts in third-party iframes.
• KG: we don't have to add anything for that? Delegating permission ability?
• KN: don't know. Think you have to delegate individual permission prompts.
• CW: next step - someone writes the proposal. Then can debate the levels we take, finer- or coarser-grained.
• KG: I prefer "full WebGPU" permission, and if you don't get that - up to UAs what they do. Some UAs want to give you software context. Don't think it's useful to forbid WebGPU as a whole. So, one bit between "full" and "restricted" WebGPU.
• KN: Apple doesn't intend to have a software impl. Chrome doesn't plan for one on Android. So there will be cases where we can't do that. Happy with shipping a base profile? We are, but not sure what Apple thinks.
• KG: think the desire was that Apple would prefer not to have a gate at all, but just let you use all of WebGPU. "full" == "restricted".
• KN: that'd be a valid implementation of the permission policy.
• KN: previous notes: https://github.com/gpuweb/gpuweb/wiki/Minutes-2022-10-19#permissions-policy-for-webgpu-and-for-unmaskhints-3483
• KN: probably don't need two-level permission prompts. Think one is reasonable.

Should the API enforce that writable storage buffer bindings don't alias each other? #1842

• CW: old issue. Closed and reopened. Thought we'd resolved that this is allowed, but say - be careful.
• (Previous(?) resolution: https://github.com/gpuweb/gpuweb/issues/1842#issuecomment-882806912)
• CW: WGSL spec now says storage buffer/texture storage can alias, be careful about data races. Doesn't say it's prevented. Think we should still allow this on the API side.
• KG: unless security concern - let's stay with this.
• CW: not a security concern.
• KN: think the blocker was Myles was concerned it could be a security concern, based on convos with the Metal team. Can't allow undefined behavior, even if among a small fixed set of possible results. I don't remember 100% though.
• KG: prev resolution - say "don't alias" in the spec. And then don't validate for it.
• KN: we did write that but Myles didn't want to approve it.
• KG: think the way to make progress - make a PR, wait for review from Myles.
• CW: sounds good.
• KG: or if Dan can help move this forward, it'd be great to get acceptance from Apple.
• DG: will need to investigate offline.

WGSL: allow bgra8unorm as texel format with extension bgra8unorm_storage #3640

• CW: if preferred swap chain format, can write to it with storage textures, which is useful for various reasons.
• CW: always works on Metal. Vulkan, need to discuss, D3D12, weirdness in the feature tables?
• JN: just submitted a comment - format tables need to be updated in the docs. Few years ago when relaxing format casting rules, we allowed BGRA UAVs. Just not captured in those tables.
• KG: part of the core issue - on the shader side, if you bind/try to draw with BGRA UAV, does the HLSL know it's BGRA? Or just a 4-channel format?
• JN: it'll swizzle it appropriately. Read it, you get RGBA.
• KG: ok. vulkan?
• CW: Vulkan has 2 things. 1) use texture swizzling or Vk component mapping when creating view. Not allowed for storage textures. 2) rely on optional feature that says "untyped storage texture" in the SPIR-V. Idea: writing raw bytes, goes through texture unit, does similar thing as D3D12. You write RGBA data, it goes out as BGRA.
• KN: Qs about Vulkan. Yes, there's an extension. There's no BGRA in shaders. Extension says, list of formats you can use this extension with doesn't include BGRA. But, you can make an RGBA view on BGRA, then bind the view. It's a bit reinterpretation, swizzle won't happen.
• KG: unfortunate. WGSL meeting yesterday, we thought this wasn't an issue, so please clarify with Vk experts internally.
• CW: we will.
• Postpone this one.
• CW: thanks Jesse for figuring out the D3D12 side of this.
• JN: I will double-check this does the expected swizzling.
• CW: if we can't require the hardware to do the swizzling, we'll need to add bgra8unorm as a format in WGSL so we can inject the swizzling.
• KN: or mandate that no API does the swizzling. :)

(stretch) Frame presentation timing queries/control? #3634

• KG: agree people ask for this a lot. Web platform rather than WebGPU issue. When is my rAF scheduled to reach the screen, or when did it? Think not important enough for us to hack this into WebGPU specifically.
• CW: think devs coming from native tend to have this question. Maybe becomes our concern to surface this with the right standards body. Need to figure out these request types.
• KG: next place to discuss this - wherever rAF is done. W3C HTML / WHATWG?
• CW: we'll discuss with our canvas team internally.
• TT: there's an issue on WGPU repo similar. Written by Conor. https://github.com/gfx-rs/wgpu/issues/2869
• GT: it's not a canvas issue. Want SVG, HTML elements to sync up. Not really a canvas discussion.
• CW: agree. Most of us aren't used to working with WHATWG / HTML specs though. Canvas folks are more familiar with the processes.
• KG: let me see if I can put together an issue for this.
• KN: we'll loop in our canvas folks.

Multithreading presentation

• KN:

Agenda for next meeting

• Take a look at the upcoming agenda items, let's try to make progress offline. Everything took less time than expected this week, which is great!
• Upcoming WebGPU API schedule:
  • December 14: APAC
  • _December 21: _Non-APAC
  • (Christmas Eve & Day, Sat Dec 24 & Sun Dec 25)
  • December 28: no meeting due to Christmas/New Year’s Day
  • January 04: APAC