Intent to Implement: WebGL 2.0 Compute

[jiaji...@intel.com]

Contact emails

jiaji...@intel.com yunch...@intel.com yan...@intel.com k...@google.com

 

Explainer

WebGL is the standard for drawing GPU-accelerated 3D graphics on the web. WebGL exposes the OpenGL ES graphics API to JavaScript, and is supported by all major browsers, operating systems, and types of graphics cards.

 

WebGL’s design philosophy is to maximize portability. Inherently, this means that some design decisions have been made to focus on the least common denominator of functionality.

 

A major gap between the current WebGL versions and what is possible on native platforms is the ability to use the general-purpose compute functionality which has been present in GPUs for a number of years. WebGL 2.0 Compute aims to address this gap.

 

There is another standard in development – WebGPU – which will also provide GPU compute functionality. We view WebGPU as the long-term direction for this technology. In the short term, it is important to provide functionality to developers so they can experiment with the combination of compute and graphics on the web. WebGL 2.0 Compute fills this need. The underlying pieces have been under development for over 18 months, and are ready to be tested. Developers’ work targeting WebGL 2.0 Compute will be easily ported to the WebGPU API, once it is available and shipping in browsers.

 

We aim to incorporate support for WebGL 2.0 Compute in Blink behind a feature flag, so that it can be tested more broadly by developers. It will take time to educate developers about how to use GPU compute functionality, and it is important to put the functionality into their hands now. We will closely track the development of the WebGPU specification; when WebGPU is broadly available, and WebGL 2.0 Compute shaders can be run easily using that specification, we aim to sunset WebGL 2.0 Compute.

 

Design doc/Spec

The specification is under development. WebGL 2.0 Compute mirrors the OpenGL ES 3.1 feature set, in similar fashion to how WebGL 2.0 mirrors the OpenGL ES 3.0 feature set.

 

TAG review has not yet been requested. If the response from Blink owners is positive, we will formalize the specification and send it for TAG review.

 

Summary

Expose OpenGL ES 3.1 functionality to WebGL via the ‘webgl2-compute’ context.

 

Motivation

WebGL is the standard for providing GPU-accelerated graphics on the web, exposing OpenGL ES-like JavaScript APIs. While the latest version of WebGL is WebGL 2.0 which was released in 2017, it is based on the underling OpenGL ES 3.0 API, which was released in 2012, and lacks many GPU features that have already been widely used in native applications.

 

Compute shaders are the most important feature in OpenGL ES 3.1, providing an efficient way to run general-purpose GPU (GPGPU) computing workloads. GPU compute is used in many domains: to accelerate machine learning algorithms, for image processing, to improve the rendering quality in game engines, and many other purposes. OpenGL ES 3.1 exposes some other features to improve both the quality and performance of GPU rendering, including multisampled textures, program pipelines, indirect drawing, and so on. All these new technologies will bring performance improvements for both graphics and computing on Web. For these reasons we think it’s necessary to expose OpenGL ES 3.1 functionality to WebGL.

 

Risks

Interoperability and Compatibility

The WebGL working group has discussed exposing OpenGL ES 3.1 functionality many times and at great length. At present, no other browsers intend to ship this WebGL upgrade.

 

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: many requests over the past several years, many on Khronos’ public_webgl mailing list.

 

Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with?

 

WebGL 2.0 Compute will be used in conjunction with the Canvas and OffscreenCanvas APIs. It will provide performance and quality improvements to WebVR and WebXR.

 

Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?

 

No. This new feature will only bring performance improvements: for example, compute shaders and indirect drawing.

 

Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is?

 

No. WebGL 2.0 Compute is a strict superset of the WebGL 2.0 API. All developers who are familiar with WebGL or native OpenGL development should easy be able to use the WebGL 2.0 Compute APIs.

 

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

 

Yes. For example, Three.js is the most popular 3D graphics library on the web, and brings WebGL’s current functionality to a larger developer audience. Compute functionality could be incorporated into such a library, significantly increasing its reach. As another example, the current popular machine learning frameworks, such as TensorFlow.js, can be easily modified to use compute shaders as the GPU acceleration path, yielding significant (~7x) performance improvements.

 

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

Unfortunately no. The Mac platform will not be supported due to limitations in Apple’s OpenGL implementation. The other platforms will all be supported. The future WebGPU standard is the way that GPU compute functionality will be exposed to the web in a completely portable fashion.

 

Link to entry on the feature dashboard

None yet. Want to receive feedback from Blink owners before proceeding to so do.

 

Requesting approval to ship?

No.

[PhistucK]

This one has a few problems...

- An interoperability issue within Chrome (macOS is not supported), which is pretty bad.

- Messing with the web developers - adding an API just so you could pretty surely remove it and make everyone update their applications (sometimes with very long release cycles, low resources and more important priorities).

- Overlapping functionality with a different feature (WebGPU) that is also under development.

(Hehe, looks like this is an intent to make available for testing rather than an intent to implement, where have you been 18 months ago when you actually started? ;) Things would have been different, without WebGPU on the road map, though shipping this by now would have suffered from the same issues)

☆PhistucK

--
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/a1abbfd4-8d83-40ba-a82e-624f313515a1%40chromium.org.

[Ken Russell]

We agree that extending WebGL with compute shader support poses some fundamental problems, and deliberately highlighted those in the Intent to Implement.

Despite the issues, we (the proposers, as well as other members of the WebGL working group) think it is worth putting GPU compute capability – behind a flag – in the hands of developers today. Developers who are particularly interested in it can begin creating compute shaders now, rather than waiting 1+ years. We all agree that WebGPU is the long-term direction for exposing GPU compute functionality to the web. WebGL 2.0 Compute is intended to provide an easier transition to WebGPU, by allowing developers to get comfortable with writing compute shaders now, and seeing what kinds of applications they can create. There are some tremendous speedups to be gained, and some kinds of graphics algorithms require compute shader support to work.

It's important to recognize that the compute shaders which developers create with WebGL 2.0 Compute will be easily ported to WebGPU once that API is released. No work will be wasted.

We can gauge developer interest once the WebGL 2.0 Compute implementation is in place. If there's strong developer support and requests for it, then we can reconsider longer-term support for the API. The impact on Blink is minimal. The bulk of the implementation is at lower levels, is already checked in to the ANGLE and Chromium code bases, and automated tests are being run on the dEQP bots on the chromium.gpu.fyi waterfall:

https://ci.chromium.org/p/chromium/g/chromium.gpu.fyi/console

For example:

https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20dEQP%20Release%20(NVIDIA)

Look for "angle_deqp_gles31_d3d11_tests" and "angle_deqp_gles31_gl_tests" in a recent run on this bot. The tests are also being run on Linux.

Does this additional information address your concerns?

-Ken

[PhistucK]

Thank you for the elaboration.

This relaxes most of my concerns ("easily ported" is not "no-work-at-all" which still requires resources shifted towards this feature and having overlapping features forever is not great). The intra-operability issue is always a concern.

Of course, as long as it is behind a flag, I do not have any practical concern. Those were mainly future concerns (when/if this gets to shipping stage).

☆PhistucK

[Ken Russell]

Thanks for your feedback and consideration. We'll proceed with integrating the feature behind a flag. Any other feedback is welcome.

[Ashley Gullen]

Based on the summary: "Expose OpenGL ES 3.1 functionality to WebGL via the ‘webgl2-compute’ context."

It sounds like this will expose other OpenGL ES 3.1 features other than compute. Is that correct? If so, why is the context name focused on compute? Sure, it might be the biggest feature, but it seems conceivable that game engines or some such would use it for the other features only and not compute. So wouldn't a context name like "webgl2.1" be more appropriate?

Further, if you actually intend from the start to eventually remove it, I think it might be worthwhile to indicate that some way, perhaps by bringing back the experimental prefix, e.g. "experimental-webgl2.1". Then it's clearer that in the long-term it might not be around any more.

--

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+unsubscribe@chromium.org.

[Ken Russell]

On Wed, Jun 27, 2018 at 2:10 AM Ashley Gullen <ash...@scirra.com> wrote:

Based on the summary: "Expose OpenGL ES 3.1 functionality to WebGL via the ‘webgl2-compute’ context."

It sounds like this will expose other OpenGL ES 3.1 features other than compute. Is that correct? If so, why is the context name focused on compute? Sure, it might be the biggest feature, but it seems conceivable that game engines or some such would use it for the other features only and not compute. So wouldn't a context name like "webgl2.1" be more appropriate?

The main feature in OpenGL ES 3.1 is compute shader support. Almost all of the other features were added in support of compute shaders. The working group felt that highlighting the intent of the feature was important.

Further, if you actually intend from the start to eventually remove it, I think it might be worthwhile to indicate that some way, perhaps by bringing back the experimental prefix, e.g. "experimental-webgl2.1". Then it's clearer that in the long-term it might not be around any more.

Thanks for this feedback. We'll consider it, but will land it under the name the working group agreed upon to start.

-Ken

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[collin.s...@gmail.com]

I may have found a bug in the Linux dev channel related to this feature. Details here: https://github.com/9ballsyndrome/WebGL_Compute_shader/issues/4

Where's the right place to report this issue?

[Qin, Jiajia]

Hi Collin,
I replied you under your link. Please try if it works with an additional flag ' --use-gl=angle '. If not, you can file a bug to chromium https://bugs.chromium.org/p/chromium/issues/entry

Thanks,
Jiajia

--
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/bbda8272-e481-47b3-8ce6-8633209dba6e%40chromium.org.

[Collin Schroeder]

You rock! thanks a bunch. 

I have been waiting for this functionality for a very long time. at least since the pyOpenCL days.  I will now get back to work!

--

-cos()