Intent to extend Origin Trial: WebGPU

[Corentin Wallez]

The origin trial for WebGPU was started in M94 and was later extended to end in M101. We are asking to extend for 4 additional releases to M105 so that we can address previous feedback from developers and gather additional ones.

Particularly important pieces of feedback that we are currently investigating are:

• The performance of WebGPU-based video processing on the Web, which after extensive efforts by partners is getting to a benchmarkable state (so we can understand the performance of the API and correct if need be).
• Missing functionality and its impact on large projects targeting WebGPU via emscripten (for example we got multiple important pieces of feedback from Unity with likely more coming)
• The expressed need to have synchronous readbacks from the GPU being available in WebGPU (something that you can do in WebGL and that at least half a dozen developers requested be added to WebGPU).
• How the recently agreed upon direction for exposing GPU identifiers in WebGPU will work for developers (since it is more limited than available in WebGL for privacy considerations).

Contact emails

cwa...@chromium.org, bcla...@chromium.org, kai...@chromium.org

Explainer

https://gpuweb.github.io/gpuweb/explainer/

Specification

https://gpuweb.github.io/gpuweb/

Design docs

https://gpuweb.github.io/gpuweb/
https://gpuweb.github.io/gpuweb/wgsl/
https://gpuweb.github.io/gpuweb/explainer/

Summary

The WebGPU API is the successor to the WebGL and WebGL 2 graphics APIs for the Web. It will provide modern features such as “GPU compute” as well as lower overhead access to GPU hardware and better, more predictable performance. WebGPU is being developed by the “GPU for the Web” W3C community group.

WebGPU is a large and complex API. Developers take time to port existing applications to it and surface feedback on functionality / performance, and TAG review is still ongoing due to the complexity of the API. We are starting to gather feedback from developers and get additional ones. Particularly important pieces of feedback that we are currently investigating are:

• The performance of WebGPU-based video processing on the Web, which after extensive efforts by partners is getting to a benchmarkable state (so we can understand the performance of the API and correct if need be).
• Missing functionality and its impact on large projects targeting WebGPU via emscripten (for example we got multiple important pieces of feedback from Unity with likely more coming)
• The expressed need to have synchronous readbacks from the GPU being available in WebGPU (something that you can do in WebGL and that at least half a dozen developers requested be added to WebGPU).
• How the recently agreed upon direction for exposing GPU identifiers in WebGPU will work for developers (since it is more limited than available in WebGL for privacy considerations).

We are asking to extend the Origin Trial to keep getting feedback from developers during their prototyping and also when they are testing with users in the wild. (identifier information for example is only useful in the latter case).

Blink component

Blink>WebGPU

Search tags

gpu, webgl

TAG review

https://github.com/w3ctag/design-reviews/issues/626

TAG review status

Still ongoing (after 11 months and regular reminders).

Risks

Interoperability and Compatibility

With positive signals (and at least WIP implementations) from all browsers, the biggest interoperability risk is the surface of the API which is quite large.

Gecko: In development (https://hg.mozilla.org/mozilla-central/file/tip/dom/webgpu)

WebKit: In development (https://github.com/WebKit/WebKit/tree/main/Source/WebGPU/WebGPU)

Web developers: Strongly positive (https://doc.babylonjs.com/extensions/webgpu) Significant interest and positive feedback from the many early adopters (Babylon.js, Earth, TF.js, sokol-gfx, and many many others).

Activation

WebGPU is not polyfillable on existing APIs and requires hardware support on the system. (software fallback is not enabled by default yet).

Security

See detailed security explainer: https://gpuweb.github.io/gpuweb/#malicious-use

Goals for experimentation

Allow developers to use WebGPU and provide feedback on the API or the shading language. We expect feedback about ergonomics, ease of use and ease of porting existing content to WebGPU, and missing features. As well as many bug reports :) Also help partners evaluate the performance of WebGPU in the wild to figure out areas of the implementation to optimize before launch.

Reason this experiment is being extended

WebGPU is a large and complex API. Developers take time to port existing applications to it and surface feedback on functionality / performance, and TAG review is still ongoing due to the complexity of the API. We are starting to gather feedback from developers and get additional ones. Particularly important pieces of feedback that we are currently investigating are:

• The performance of WebGPU-based video processing on the Web, which after extensive efforts by partners is getting to a benchmarkable state (so we can understand the performance of the API and correct if need be).
• Missing functionality and its impact on large projects targeting WebGPU via emscripten (for example we got multiple important pieces of feedback from Unity with likely more coming)
• The expressed need to have synchronous readbacks from the GPU being available in WebGPU (something that you can do in WebGL and that at least half a dozen developers requested be added to WebGPU).
• How the recently agreed upon direction for exposing GPU identifiers in WebGPU will work for developers (since it is more limited than available in WebGL for privacy considerations).

We are asking to extend the Origin Trial to keep getting feedback from developers during their prototyping and also when they are testing with users in the wild. (identifier information for example is only useful in the latter case).

Ongoing technical constraints

None

Debuggability

Warnings and errors are exposed via dev tools. Specialized tools for debugging are TBD.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No

This feature will not be available in Origin Trial on: - Android because adding Android support is a lot of engineering that we're scheduling to happen between the Origin Trial and the shipment of WebGPU. - Windows 7 and 8 since they don't have D3D12. Support will be extended to these versions of Windows after the first version of WebGPU is shipped. - Other devices that don't support D3D12/Metal/Vulkan or don't have a GPU with good enough minimum specifications.(maybe) - ARM devices if we don't find time to test on ARM platforms before the Origin Trial starts. The goal is that WebGPU will eventually be supported in hardware on the vast majority of systems on all Blink OSes and have software fallback on the others.

Is this feature fully tested by web-platform-tests?

Yes

DevTrial instructions

https://github.com/gpuweb/gpuweb/wiki/Implementation-Status#chromium-chrome-edge-etc

Flag name

--enable-unsafe-webgpu

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1156646

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1156661

Estimated milestones

OriginTrial desktop last	101
OriginTrial desktop first	94

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6213121689518080

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/dxqWTSvyhDg/1UDaFD17AQAJ
Intent to Experiment: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/K4_egTNAvTs

Intent to Extend: https://groups.google.com/a/chromium.org/g/blink-dev/c/l-QcZ7qOcUQ

[Yoav Weiss]

Thanks for tackling this large , important and complex capability! :)

As this extension will bring the OT to 12 milestones, which is the typical limit of time we let OTs run (to reduce burn-in risk), I'd love to better understand the higher level plan.

Are you planning for this to be the last OT extension, and planning to ship around M105? Are you planning to pause the OT at some point, to reduce the burn-in risk? Something else?

Are the Firefox and Safari implementations passing the WPTs? That could be reassuring from an interop perspective.

[Corentin Wallez]

Hey Yoav,

The W3C group is looking to finish a first version of the spec ASAP and while standardization always has a bunch of unknowns, we want to get to a stable spec in months, not quarters. So for Chromium our hope was that we could keep the OT going until shipping, with maybe a pause of one release in the middle. Burn-in is always a risk but fairly minimal for WebGPU because all browsers are implementing and horizontal reviews seem to have little comments that would change the shape of the API drastically. (so we're not in a situation like when WebVR turned into WebXR). We've also been doing rolling deprecations during the OT and developers all upgraded in a timely fashion.

Of course we might be biased in evaluating the risk of burn-in but it seems minimal, so extending OTs for 12 milestones (or even longer) doesn't look scary. Happy to discuss more obviously :)

Re: WebGPU WPT in Firefox and WebKit, short answer is that they aren't running the tests yet, but looking to.

• WebKit started implementing WebGPU again actively a couple weeks ago and assured they wanted the vast majority of their tests to be the WPT ones we develop (and that they are going to contribute to if they find holes). They asked for pointers on how to run the WebGPU CTS through WPT so they must be looking at doing that.
• I thought Firefox ran WebGPU WPT on CI but it seems it later got disabled. Kelsey Gilbert confirmed it: "Not as part of Firefox CI yet, but yes we are working on it". wgpu the library used to implement WebGPU in Firefox, is running the tests through Deno, which provides coverage of most of the code. (from our experience in Chromium). I don't know the pass rate of wgpu though.

Cheers,

Corentin

[Yoav Weiss]

LGTM to continue experimenting till M105 (inclusive) but no further.

On Wed, Mar 23, 2022 at 12:57 PM Corentin Wallez <cwa...@chromium.org> wrote:

Hey Yoav,

The W3C group is looking to finish a first version of the spec ASAP and while standardization always has a bunch of unknowns, we want to get to a stable spec in months, not quarters. So for Chromium our hope was that we could keep the OT going until shipping, with maybe a pause of one release in the middle. Burn-in is always a risk but fairly minimal for WebGPU because all browsers are implementing and horizontal reviews seem to have little comments that would change the shape of the API drastically. (so we're not in a situation like when WebVR turned into WebXR). We've also been doing rolling deprecations during the OT and developers all upgraded in a timely fashion.

Of course we might be biased in evaluating the risk of burn-in but it seems minimal, so extending OTs for 12 milestones (or even longer) doesn't look scary. Happy to discuss more obviously :)

Extension beyond the 12 milestone mark would require 3 LGTMs and significant analysis of the risks involved. Pausing the OT for a release would go a long way towards reducing the risks, so it might be worthwhile for y'all to consider.

 

Re: WebGPU WPT in Firefox and WebKit, short answer is that they aren't running the tests yet, but looking to.

• WebKit started implementing WebGPU again actively a couple weeks ago and assured they wanted the vast majority of their tests to be the WPT ones we develop (and that they are going to contribute to if they find holes). They asked for pointers on how to run the WebGPU CTS through WPT so they must be looking at doing that.
• I thought Firefox ran WebGPU WPT on CI but it seems it later got disabled. Kelsey Gilbert confirmed it: "Not as part of Firefox CI yet, but yes we are working on it". wgpu the library used to implement WebGPU in Firefox, is running the tests through Deno, which provides coverage of most of the code. (from our experience in Chromium). I don't know the pass rate of wgpu though.

Thanks! May be interesting (but not blocking) to run those WPTs manually and see if they pass. Or we could wait for them to integrate them into their CI :)

[Corentin Wallez]

On Wed, Mar 23, 2022 at 1:13 PM Yoav Weiss <yoav...@chromium.org> wrote:

LGTM to continue experimenting till M105 (inclusive) but no further.

Thank you!

 

On Wed, Mar 23, 2022 at 12:57 PM Corentin Wallez <cwa...@chromium.org> wrote:

Hey Yoav,

The W3C group is looking to finish a first version of the spec ASAP and while standardization always has a bunch of unknowns, we want to get to a stable spec in months, not quarters. So for Chromium our hope was that we could keep the OT going until shipping, with maybe a pause of one release in the middle. Burn-in is always a risk but fairly minimal for WebGPU because all browsers are implementing and horizontal reviews seem to have little comments that would change the shape of the API drastically. (so we're not in a situation like when WebVR turned into WebXR). We've also been doing rolling deprecations during the OT and developers all upgraded in a timely fashion.

Of course we might be biased in evaluating the risk of burn-in but it seems minimal, so extending OTs for 12 milestones (or even longer) doesn't look scary. Happy to discuss more obviously :)

Extension beyond the 12 milestone mark would require 3 LGTMs and significant analysis of the risks involved. Pausing the OT for a release would go a long way towards reducing the risks, so it might be worthwhile for y'all to consider.

 

Sounds good, I really hope by then we'll be ready for launch, with the potential gap of one release. We need to figure out the implications but it's likely we can do a pause.

[⸻ “‪How Things Work‬”]

I know this is quite late, but is WebGPU still due to be implemented after Build 109? (So 110 and above?)