Skip to content

GPU Web 2023 08 09

Jump to bottom
Corentin Wallez edited this page Aug 15, 2023 · 2 revisions

GPU Web 2023-08-09

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

Chair: Corentin

Scribe: Ken

Location: Google Meet

Tentative agenda

  • Administrivia
    • Still need to invite PING
  • CTS Update
  • “Tacit Resolution” Queue
  • Extended brightness range rendering #4239
  • WebGPU Compatibility Mode #4266
  • (stretch) GitHub Milestones
  • Agenda for next meeting

Attendance

  • Apple
    • Mike Wyrzykowski
  • Google
    • Brandon Jones
    • Chris Cameron
    • Corentin Wallez
    • Gregg Tavares
    • Kai Ninomiya
    • Ken Russell
    • Loko Kung
    • Shannon Woods
    • Shrek Shao
    • Stephen White
  • Microsoft
    • Rafael Cintron
  • Mozilla
    • Kelsey Gilbert
    • Teodor Tanasoaia
  • Nvidia
    • Anders Leino

Administrivia

  • Still need to invite PING to one of our meetings
    • On Corentin's and Kelsey's action items

CTS Update

  • KN: CTS work on Compat continuing. Investigating performance - running CTS on Chromium's CI is slow. Found some major things to fix around listing the tests.
  • No other progress on CTS. Kai will finish WPT chunking this month.
  • Ryan working on AbstractFloat tests. Complicated. He's making them robust.

“Tacit Resolution” Queue

  • Race between createPipelineAsync and device loss #1629 (comment)
    • KN: if in middle of async operation, and device is lost, there's a race between when the two operations complete.
    • In device timeline, just before sending message to content pipeline to reject/resolve, we check the device status again. If lost, pipeline creation will pretend to pass.
  • getCompilationInfo on lost device #1629 (different comment)
    • If you do getCompilationInfo after device is lost, will return empty list and pretend everything was OK.

Extended brightness range rendering #4239

  • CC: clarified some behaviors on the issue - any questions?
  • CC: just choosing the right wording - adding no-clamp option, and defining what happens during clamping. Just take AI for next time to add new language?
  • KG: want a chance to go over this.
  • CC: ok, no worries.

WebGPU Compatibility Mode #4266

  • Stephen White presenting
  • Extend WebGPU's reach to devices that don't support the latest APIs. D3D11 < Resource Tier 2, and OpenGL ES (desktop, Android, ChromeOS).
    • 100s of millions of users.
    • Great for community, developers, and larger web properties which require larger reach.
  • Couple of things to highlight in the proposal:
    • Lack of texture views in OpenGL ES. We didn't come to internal Google consensus on how to handle this. Spectrum of proposals - run largest set of content with perf cliffs, or have no perf cliffs. Good to decide as a group.
    • Impl complexities - lack of separate textures and samplers. Padding out structures and interface blocks. (In GLSL, no way to modify struct layout.)
  • KR: pointed out nice thought that's gone in, like heuristics deciding between 2D texture arrays and cube maps based on # of levels.
  • RC: how many people wouldn't be served by WebGPU Compat?
    • SW: don't have firm numbers. Tests in Chrome Canary couldn't be run in Stable yet. We will gather this data. But, still sizable chunk of users that would need SW rasterization.
    • CW: Android devices < GLES 3.1 (shrinking user population - maybe 5% of devices?), and Windows 10 devices with D3D11 without FL 11. ~5% of Windows devices Chrome sees. Sizable chunk, but relatively small fraction.
    • https://developer.android.com/about/dashboards 6.51% GLES2.0 + 7.35% GLES3.0
    • RC: are there still Android devices coming out with only GLES 2?
    • CW: recently some did ship with GLES2. We hope that stops soon.
  • MW: last time spoke about this with Myles, slightly opposed - but want to sync back up with him.
  • CW: overarching point: when our browsers ship WebGPU we want as much content to run on it as possible. Better API and translates better to the underlying APIs (even OpenGL). Getting it running on all browsers raises the interest level of developers.
    • MW: concern is balancing that with divergence of the spec, and what will be used with Compat.
    • KN: sounds familiar from last time this group discussed this. Have given this thought. Either we have a divergence between WebGPU and WebGPU-Compat, or WebGPU and WebGL. That's a much larger divergence, worse situation to be in. Of course there are still devices that will only get WebGL, but that's a smaller population.
  • TT: FL support for D3D11. Does this support FL11 specifically, or lower?
    • SW: FL11. To get compute, we need 11_0. 11.1 guarantees enough that you can do full WebGPU. Minimum is 11_0 + Resource Tier 2. So Compat handles 11_0 prior to Resource Tier 2.
    • TT: there's optional compute shader support for FL 10. Does that help? Don’t know the differences between SM4 and SM5.
    • SW: I have a doc where I looked into this - will get back to you.
    • TT: saw proposal mainly focusing on GLES. Any constraints imposed by FL11?
    • SW: don't think there was anything further. GLES was the most constraining.
  • KG: would be extra cool to have justification include not-just-ES. E.g., if true for D3D11 FL 11_0, that justification would help.
    • SW: will add that. Probably just the limits that were common.
  • SW: a lot of this was determined empirically by building a backend and see what breaks. And a lot of this was built on top of ANGLE with D3D11. If I diff that with native ES drivers, you could see what was missing in the D3D11 path.
    • CW: does wgpu have a D3D11 backend? Any constraints there?
    • KG: we're not actively developing it - community project - hard to speak to the status.
  • KG: there was a point, we're not quite in alignment with the statement that when we launch WebGPU, we want as much content to run it as possible.

(stretch) GitHub Milestones

  • KN: editors discussed this - would like to better define our milestones. Currently:
  • Editorial fixes.
  • Features we want to add now to the spec. Features that at least Firefox intends to add before shipping. (HTMLImageElement for example.)
  • Things we want to add after feature unfreeze.
  • Things later.
  • This is roughly how I want to define the milestones.
  • KG: did you come up with strawman names?
  • KN: don't have good ones. V1 for editorial stuff? "Now", "Soon" and "Later"?
  • CW: can we use Milestone 2 for "Soon"?
  • KR: would suggest a numbering scheme so we can move things from "Later" and still know which version of WebGPU (roughy) they landed in after the fact.
  • CW: OK, we should re-triage M2 at some point.
  • KN: will be an exercise to re-triage different companies' priorities for various things. Want to define the milestones first. Currently have "Polish-Post-V1" milestone, not sure what it means.
  • CW: more Milestone 2. Need to re-triage that as well.

Agenda for next meeting

Clone this wiki locally