Intent to Implement: WebGPU

[Corentin Wallez]

Contact emails

cwa...@google.com, k...@google.com

Spec:

Work-in-progress IDL: https://github.com/gpuweb/gpuweb/blob/master/design/sketch.webidl

The “GPU for the Web” community group is approaching resolution on most-high level issues, but hasn’t looked at the detail or user-experience of the API yet.

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.

Motivation

Applications on the Web are becoming ever more interactive, which increases the demand for programmable 3D graphics, image processing, and GPU access in general. WebGL and WebGL 2 fulfill some of this demand, but do not match the features or performance of modern native graphics APIs.

WebGPU will close the gap in terms of performance, and introduce “GPU compute” functionality to the Web. This will help porting native applications to WASM that require native features, and will unlock the performance of GPU-accelerated scientific computing on the Web (including machine learning).

In addition WebGPU will give developers more predictable performance by being in the style of “explicit GPU APIs” and by being designed to map efficiently on all modern native graphics APIs.

Risks

Interoperability and Compatibility

WebGPU has public support from Edge, Firefox and Safari with representatives from each of them in all of the group’s weekly meetings (notes). There already are customers interested in using WebGPU when it is available, such as TensorFlow.js, Yandex Maps, as well as game engines Unreal Engine and Unity3D.

An interoperability risk is the size of the API and the fact that it includes a GPU language, however the members of the community group have experience testing such a large surface area with WebGL.

Ergonomics

WebGPU will be used in conjunction with Canvas APIs and will interact closely with WebAssembly to have fast bindings to Blink. There will be other interactions with WebVR/WebXR and HTML’s <img> and <video> elements. WebGPU is designed to be non-blocking and to be usable across workers.

Activation

WebGPU is targeting developers already familiar with graphics APIs, and it won’t be possible to mix it with WebGL code easily. However, like WebGL, we expect most usage of WebGPU to come through frameworks like three.js or game engines like Unity3D, so developers using these will get the WebGPU wins for free. We intend to create significant amounts of beginner and intermediate documentation in addition to the spec.

Debuggability

No particular support for this feature. Debuggability could be provided as an extension or JS module like SpectorJS for WebGL.

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

The WebGPU API will be present on all six platforms, but creating WebGPUDevice will require the native platform to expose a modern graphics API:

• Vulkan on Windows 7/8, Linux, Chrome OS, Android and Android WebView

• Metal on Mac

• Direct3D 12 on Windows 10

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

Not yet. There will be a shared test suite but it isn’t clear yet if it will be part of web-platform-tests or a standalone test suite.

Requesting approval to ship?

No.

[Ian Kilpatrick]

Horray!

As per: https://docs.google.com/document/d/1vlTlsQKThwaX0-lj_iZbVTzyqY7LioqERU8DK3u3XjI/edit#bookmark=kix.p5nalpch13qw

Please file a TAG review or comment on why the tag review process is being skipped.

Thanks,

Ian

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM4LO64JVWrop%2BfUc-tnWZ4iB4GMGrvyKkRB4Qnpk7wzGiN_Eg%40mail.gmail.com.

[Ken Russell]

If I may reply in Corentin's stead: the proto-spec for WebGPU is still in a very early state. Personally, I think it's too early to start a TAG review, because the community group still needs to hash out several aspects of the spec and IDL before all the members are comfortable enough with the state of it.

Is that acceptable? In order to have multiple Chromium developers contribute to the implementation, it will be much easier to land pieces of it on trunk behind a flag, rather than carrying forward a separate repository or branch – which was done for some months previously.

Thanks,

-Ken

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpQAmG%3DgG6uOQZOTnE2uY3847GLuDdRtMBza7gNJxcCX_g%40mail.gmail.com.

[t...@themesurgeons.com]

I'll test it it.

[Corentin Wallez]

Hey Ian,

The reason why we didn't file for a TAG review yet are exactly what Ken said. We want to have in browser prototypes to flesh out more unknowns before we ask for the review. Also Microsoft's TAG representative (Travis) already gave feedback that we incorporated.

Cheers,

Corentin

[Ian Kilpatrick]

Hey Corentin,

I'd err on the side of filing for the TAG review early, rather than later.

The TAG review is more of a TAG "discussion". The process explicitly isn't a "TAG signs off on this design", rather a collaborative effort, and it's explicitly OK to have half formed ideas about the design space.

Ultimately its up to you, but from my point of view there is only upside to filing for the TAG review earlier rather than later.

Thanks,

Ian

[Corentin Wallez]

Hey Ian,

Sorry for the late answer. I'll bring up the idea of an early TAG review/discussion to the group.

Cheers,

Corentin