Minutes 2023 04 05

GPU Web 2023-04-05

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

Chair: KG

Scribe: KR

Location: Google Meet

Tentative agenda

• Administrivia
• CTS Update
• “Tacit Resolution” Queue
  • Expose namespaces only in secure contexts, like interfaces. #4002
  • uncapturederror shouldn't fire after device loss #4017
• requestAdapterInfo() should be required to prompt (in at least some circumstances) #3962
• add query for list of WGSL software/shader-lang extensions (e.g. do-while) #3875
• Almost no PowerVR devices satisfy minimum Vulkan requirements #3631
• maxBindingsPerBindGroup has arbitrary limit of 640 #3864
• Proposal: formats-tier-1 extension #3837
• Occlusion Query results seem under specified #3895
• Agenda for next meeting

Attendance

• Apple
  • Dan Glastonbury
• Google
  • Brandon Jones
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
• Intel
  • Jiawei Shao
  • Shaobo Yan
  • Zhaoming Jiang
• Microsoft
  • Rafael Cintron
• Mozilla
  • Jim Blandy
  • Kelsey Gilbert

Administrivia

• Going to call these meetings "Pacific" and "Atlantic" time zones rather than "APAC" and "non-APAC"

CTS Update

• KG: working on some blockers for Firefox's CTS runs
  • Little spec changes like canvas context.getPreferredFormat() - now gpu.getCanvasPreferredFormat()
• KN: some work on WGSL testing side. Finishing moving to a framework that lets us exhaustively test floating-point stuff. Team's been focusing on other things.
• KR: also, we encourage test contributions! If you're wondering where areas are uncovered by the CTS - please ask Kai or the team on the Matrix chat.
• KN: if you find regressions, bugs, issues, and you fix them - and you can write regression tests - please do add CTS tests for these. They're likely to be issues that crop up in other WebGPU implementations, and the CTS is a good central place for these tests.

“Tacit Resolution” Queue

• Expose namespaces only in secure contexts, like interfaces. #4002
  • FYI, mostly in case anyone was using the IDL verbatim.
  • KN: editorial mistake. Just FYI.
  • JB: Moz's Web IDL compiler can't do secure context interfaces right now 🙂
  • KN: you can implement these as interfaces.
• uncaptured error shouldn't fire after device loss #4017
  • There shouldn’t be a redundant signal that the device is lost, so developers will be sure to use the correct (reliable) signal for recovery handling. Probably something we already agreed upon years ago; IIRC this was in the design principles for error handling.
• Add GPU.wgslLanguageExtensions to list the supported WGSL software extensions #3941
  • the field is navigator.gpu.wgslLanguageFeatures (not shadingLanguageFeatures)
  • the interface name is WGSLLanguageFeatures (not GPUWGSLLanguageFeatures)
  • it's a readonly setlike<DOMString>

requestAdapterInfo() should be required to prompt (in at least some circumstances) #3962

• KG: while requestAdapterInfo() is designed to allow implementing by prompting some of the time, some browser impls are likely to never prompt. Authors are likely to expect that this won't prompt. Suggesting that browsers be required to prompt in some situations at least.
• KG: concern - browsers that don't want to prompt, perhaps they're sanitizing the data sufficiently well. (There was another concern that I didn't capture - KR). If Apple does some calculations and decides to prompt for this sometimes, don't know how to handle this.
• KG: what kind of proposal would make this work? Concern that there isn't one. Some of this counts as, what is fingerprinting and what do you want to do about it?
• KN: think the compatibility risk is real, and this is why we removed support for unmaskHints() in Chrome. Shipping without a prompt, and then adding a prompt, can be breaking for websites.
• KN: think for V1, think we shouldn't try to answer the question of whether there should be a prompt. Way outside the scope of this group. Don't want to block V1 on that decision.
• KN: thinking, for V1 - simply say you can't do this. Remove support for the unmaskHints API from V1 of the spec until that's answered.
• KN: in the end - think the way we should think about this - not I want more information from the browser, but, please upgrade me from what I get by default, to what I'd get by asking the user. Most permission APIs - you're asking for, please prompt the user for what I want. No ambiguity for wanting geolocation, etc. permission. Expectation should be, there's likely to be a prompt. What we give in the prompt should be up to the UA. Think we should slightly change our expectation of what this is asking for.
• JB: be nice to put this off until next week, until more people are present for the discussion.
• KG: OK. Let's think more about it.

add query for list of WGSL software/shader-lang extensions (e.g. do-while) #3875

• Moved to #3941?

Almost no PowerVR devices satisfy minimum Vulkan requirements #3631

• KG: Suggesting to close, older PowerVR devices won't be supported in core, and then post-V1, remove the thing we added so that we could support more PowerVR devices in the future
• KN: can't remove the limit, but can remove the validation of it. Not urgent.
• KR: What happens if you request to raise the limit, but the limit doesn’t exist?
• KN: We wouldn’t remove the limit, we just wouldn’t do validation for it.
• KN: Also, we have a thing in the spec where if you ask for a too-low limit, we will give you back at least the minimum limit, which is higher than you requested.
• KN: where we left things before, we were going to see whether we were worried about this - result of investigation was, we aren't worried about this.

maxBindingsPerBindGroup has arbitrary limit of 640 #3864

• KG: everyone seems happy to change this to 1000.
• KN: resolved already.

Proposal: formats-tier-1 extension #3837

• KG: will postpone until Teo can attend next week
• KN: big question to answer: do we want to get a first tier into V1? To remove the RG11B10UFloat renderable extension? Probably going to leave that in because Chrome's shipping already.

Occlusion Query results seem under specified #3895

• KN: we think this is a driver bug. :) Not confident that this should be the case everywhere.
• KG: Q is - can we implement the thing we said we would? Even if we know this behavior is here, we can know no draw call happened, and write 0s there. Then it's implementable.
• GT: sounds good to me, as long as we're OK with working around driver bugs instead of changing the spec.
• KN: as long as we have a way to work around it. Even if not required by Metal, should be relatively straightforward to do this. Just paper over the issue.
• KG: tacit proposal on my part - if you don't have a draw call between these two points, the occlusion query result's zero.

Agenda for next meeting