Hello, WebGL 2.0 Compute #7612

hujiajie · 2018-12-05T10:25:39Z

WebGL 2.0 Compute is an experimental superset of WebGL 2.0, provided by Chrome/Chromium behind the flag --enable-webgl2-compute-context. It exposes OpenGL ES 3.1 functionality, notably compute shader, to WebGL via the webgl2-compute context[1][2]. The patchset adds a new flag -s USE_WEBGL2_COMPUTE= and implements preliminary support for this feature, in the hope that it can benefit applications in the field of machine learning, image processing, gaming, etc. A ray tracing demo is also provided as a test, but sadly it's skipped in CI because the Mesa software renderer is too slow and lacks certain OpenGL extensions for WebGL 2.0 Compute to work.

[1] https://www.khronos.org/registry/webgl/specs/latest/2.0-compute/
[2] https://groups.google.com/a/chromium.org/d/topic/blink-dev/bPD47wqY-r8/discussion

hujiajie · 2018-12-05T10:27:11Z

The patchset is temporarily based on #7105.

hujiajie · 2018-12-05T10:27:31Z

cc @gyagp @qjia7 @kainino0x @kenrussell

kripken · 2018-12-05T19:14:02Z

src/parseTools.js

@@ -8,6 +8,58 @@

 //"use strict";

+var makePPEnum = (function() {


this change could be a separate PR?

I think the topic was discussed before, and the hope was we can avoid adding a full parser like this, and can use eval instead?

kripken · 2018-12-05T19:14:44Z

emscripten.py

@@ -582,10 +582,13 @@ def read_proxied_function_signatures(asmConsts):


 def compile_settings(compiler_engine, libraries, temp_files):
+  settings = shared.Settings.to_dict()
+  settings.update((key, int(value)) for key, value in settings.items() if isinstance(value, bool))
+


these changes also seem like they should be in separate PRs?

Yes, it's part of #7105

kripken · 2018-12-05T19:15:39Z

src/library_gl.js

@@ -33,14 +33,14 @@ var LibraryGL = {
    currentContext: null,
    offscreenCanvases: {}, // DOM ID -> OffscreenCanvas mappings of <canvas> elements that have their rendering control transferred to offscreen.
    timerQueriesEXT: [],
-#if USE_WEBGL2
+#if USE_WEBGL2 || USE_WEBGL2_COMPUTE


Perhaps WEBGL2_COMPUTE should require that WEBGL2 is on, so we don't need to || here?

I did hesitate for some time if USE_WEBGL2_COMPUTE should imply USE_WEBGL2. I made the current choice because

WebGL 2.0 is provided by the webgl2 context (WebGL2RenderingContext) and WebGL 2.0 Compute is provided by the webgl2-compute context (WebGL2ComputeRenderingContext), so WebGL 2.0 Compute is not simply an extension of WebGL 2.0.

For a native application in C/C++, the two contexts are usually created with different minor version number.

It gives me the impression that USE_WEBGL2 and USE_WEBGL2_COMPUTE should exist at the same level but be exclusive to each other. Tens of USE_WEBGL2 || USE_WEBGL2_COMPUTE is bad, but the other style sounds slightly worse to me at the moment.

You could probably introduce another symbol, like ~~HAVE_WEBGL2 or AT_LEAST_WEBGL2~~ ALLOW_WEBGL2, that would be more clear in its intent.

As another proposal, use #if WEBGL_MAJOR_VERSION >= 2. Not sure if it's better or not.

kripken · 2018-12-05T19:18:38Z

I don't have the full context for compute (will need to look into it), but some initial comments above.

Overall this is very nice work! The compute-specific changes in this PR look generally ok to me, my only concerns at this point are some of the support code like the parsing and python changes etc., but those can be separated out I think.

hujiajie · 2018-12-06T01:39:56Z

Glad to know the overall opinion. Will address the preprocessor concerns next.

kainino0x · 2018-12-06T03:14:59Z

Perhaps it would be useful for review to link to the compare between #7105 and here, so that the changes are not squashed together:
hujiajie/emscripten@preprocessor-rework...webgl2-compute

kenrussell · 2018-12-12T00:09:27Z

This is tremendously exciting @hujiajie ! Please follow @kripken and @kainino0x 's advice to get this landed. Great work!

kripken · 2018-12-13T01:07:46Z

Ok, the preprocessor issues should be sorted out now after #7651 which just landed. Rebasing this to contain just the WebGL 2 Compute stuff should now be possible.

hujiajie · 2018-12-13T01:22:53Z

Really appreciate the effort! I'll post an update in a day or two.

juj · 2018-12-13T11:08:15Z

Given that WEBGL2_COMPUTE implies required WebGL2 support, and now that Alon landed that excellent more flexible preprocessor support, how about introducing a new flag

-s MAX_WEBGL_VERSION=xy

which can take one of values 10, 20 or 21, for WebGL 1.0, WebGL 2.0, and WebGL 2.0 Compute respectively. Because this is a tower of dependencies that imply each other, then we change to

-#if USE_WEBGL2 || USE_WEBGL2_COMPUTE
+#if MAX_WEBGL_VERSION >= 20

-#if USE_WEBGL2 && USE_WEBGL2_COMPUTE
+#if MAX_WEBGL_VERSION >= 21

Then let's change the -s USE_WEBGL2=1 flag in command line frontend to alias as if one had passed in -s MAX_WEBGL_VERSION=20, and so, if developer wants to enable WebGL 2.0 Compute support, they would pass in linker flag -s MAX_WEBGL_VERSION=21. Then we can drop the -s USE_WEBGL2=1 and -s USE_WEBGL2_COMPUTE=1 flags altogether.

Note that the meaning of current -s USE_WEBGL2=1 flag does not mean that the compiled page would strictly use WebGL 2.0, but instead, it means that the compiled page will be enabled to target WebGL 2.0 (but it may also choose to create WebGL 1.0 contexts at runtime).

In the future, the above scheme will allow us to add another flag, -s MIN_WEBGL_VERSION=10/20/21 in the same manner to enable a developer to e.g. say -s MIN_WEBGL_VERSION=20 to mean "This application will never work on WebGL 1.0, so do not even bother compiling in WebGL 1.0 support code, that would just waste generated code space". With MIN_WEBGL_VERSION and MAX_WEBGL_VERSION, developers can specify at compile time the API range they wish to care about, e.g. -s MIN_WEBGL_VERSION=10 -s MAX_WEBGL_VERSION=20 would mean that the page will target 1.0 and 2.0, and -s MIN_WEBGL_VERSION=10 -s MAX_WEBGL_VERSION=10 would mean the page is strictly WebGL 1.0 only, and so on.

juj · 2018-12-13T11:12:07Z

src/library_gl.js

+    // WebGL 2.0 Compute is deemed to be a design mistake in naming. The
+    // following constants will make the life easier.
+    WEBGL2_COMPUTE_MAJOR_VERSION: 2,
+    WEBGL2_COMPUTE_MINOR_VERSION: 1,


These two lines would introduce regression on pages that target WebGL 2.0 only, but not WebGL 2.0 Compute. Btw about the comment here - is there a future direction to rename WebGL 2.0 Compute to WebGL 2.1 officially? Or how does the comment relate to current thinking? (If the API name "WebGL 2.0 Compute" is deemed to be permanent, we do not want to retain judgement in comments, so could leave that out, even if we do feel it was the wrong call)

Sorry, I forgot to remove the subjective comment before committing.

I do not think WebGL 2.0 Compute will be renamed to WebGL 2.1 or 3.0 in the near future. Maybe @kenrussell or @gyagp have more insight on this.

And can you elaborate more on the regression? Is it about code size?

As Apple stops to advance OpenGL, WebGL 2.0 Compute can't run on macOS/iOS. Given it's not a general solution for all platforms, the decision from Khronos WebGL Working Group was to make it an extension, rather than a concrete version.

And can you elaborate more on the regression? Is it about code size?

Oh sorry, yeah, meant here a regression on code size specifically.

I do not think WebGL 2.0 Compute will be renamed to WebGL 2.1 or 3.0 in the near future.

If WebGL 2.0 Compute will not be renamed to WebGL 2.1, but we still have items like

WEBGL2_COMPUTE_MAJOR_VERSION: 2, WEBGL2_COMPUTE_MINOR_VERSION: 1,

making Emscripten treat WebGL 2.0 Compute as if it was WebGL 2.1, why should we diverge from them and call it 2.1 if Khronos WebGL WG does not? Is there a danger of the working group introducing a "real" WebGL 2.1 at some point after this, and then we would be left with a collision with version numbering?

The WebGL version number is heavily used in library_gl.js for comparison, so I suppose WebGL 2.0 Compute also needs a numerical representation for this, but it looks inappropriate to just use 2.0. A real WebGL 2.1 could be the risk, and I haven't got a better idea yet.

juj · 2018-12-13T11:15:50Z

src/library_gl.js

+            webGLContextAttributes['minorVersion'] = defaultContext.minorVersion;
+            break;
+          }
+        }


The above code would introduce a code size regression for WebGL 1.0 and WebGL 2.0 code when WebGL 2.0 Compute was not being targeted. I can appreciate the desire to build simple looking code, though we need to come up with a way to do this in a manner that will at least Closure optimize away well when WebGL 2.0 Compute is not being targeted (and when WebGL 2.0 is not being targeted either)

juj · 2018-12-13T11:18:06Z

src/library_gl.js

@@ -720,18 +760,19 @@ var LibraryGL = {
      var context = {
        handle: handle,
        attributes: webGLContextAttributes,
-        version: webGLContextAttributes['majorVersion'],
+        majorVersion: webGLContextAttributes['majorVersion'],
+        minorVersion: webGLContextAttributes['minorVersion'],


The three above code blocks also would regress code size for WebGL1 and WebGL 2. Instead of majorVersion and minorVersion, I think it'd be better to do integers 10, 20 and 21, the generated code size will be smaller that way.

It was over-engineered because 210 can mean either 2.10 or 21.0, and 3.0 should be larger than 2.10. But I'm not opposed of your suggestion considering it's pretty safe to leave the situation unhandled until it really happens. Just a little concerned about the readability for now, so looking forward to others' opinion.

juj · 2018-12-13T11:18:47Z

src/library_gl.js

+        } else if (GL.currentContext.majorVersion == 2 && GL.currentContext.minorVersion == 0) {
+          glVersion = 'OpenGL ES 3.0';
+        } else if (GL.currentContext.majorVersion == 1 && GL.currentContext.minorVersion == 0) {
+          glVersion = 'OpenGL ES 2.0';


This would also regress WebGL 1.0/WebGL 2.0 code size.

juj · 2018-12-13T11:19:08Z

src/library_gl.js

+        } else if (GL.currentContext.majorVersion == 2 && GL.currentContext.minorVersion == 0) {
+          major = 3;
+          minor = 0;
+        }


juj · 2018-12-13T11:20:02Z

src/library_gl.js

+          prelude = '#version 310 es\n';
+        } else if (GL.currentContext.majorVersion == 2 && GL.currentContext.minorVersion == 0) {
+          prelude = '#version 300 es\n';
+        }


juj · 2018-12-13T11:21:39Z

system/lib/gl/gl.c

+  if (!strcmp(name, "glDispatchCompute")) return emscripten_glDispatchCompute;
+  if (!strcmp(name, "glBindImageTexture")) return emscripten_glBindImageTexture;
+  if (!strcmp(name, "glMemoryBarrier")) return emscripten_glMemoryBarrier;
+  if (!strcmp(name, "glMemoryBarrierByRegion")) return emscripten_glMemoryBarrierByRegion;


This also regresses code size, in a particularly tricky way. For this we should migrate to codegenning this differently per API level.

FYI, many ES 3.1 APIs are still not added here, so the code size is expected to be increased further. Can we leave codegenning for future improvement?

Is the regression from adding all these strings? Or is it somehow specific to glMemoryBarrierByRegion? Can this entire block just be inside of an ifdef?

I think the regression is that these lines keep alive each of those functions whose address they return. So the compiler can't dce them out, they are all used.

We do build this file separately for when GL emulation is present. We could build separate versions for the different GL levels, to reduce the problem. That code is in tools/system_libraries.py.

+1, sounds like a reasonable fix to me. FYI @hujiajie: In tools/system_libs.py, I'm looking at create_gl. It does flags += legacy_gl_emulation_flags(libname). I think the suggestion is to add another flags += webgl2_compute_flags() similar to that.

IIUC, the idea has already been implemented in ef230f5. I'm rebasing on top of that.

juj · 2018-12-13T11:29:20Z

Cool work!

One other direction we should investigate here is that instead of adding WebGL 2.0 Compute support in to library_gl.js, which currently has accumulated WebGL 1.0, WebGL 2.0 and Legacy GL emulation, it would be better to not go further down that hole, and instead introduce WebGL 2.0 Compute support in e.g. library_webgl21.js file for all entry points that are unique to it. The existing monolithic library_gl.js is a bad practice, it's something that has been long desired to be split up into library_webgl10.js, library_webgl20.js and library_glemu.js files, so introducing WebGL 2.0 Compute support to its own file library_webgl21.js would keep the strain from such a split lighter and avoid continuing the bad practice.

Another benefit of separate files is that if we did the above -s MAX_WEBGL_VERSION=21 kind of scheme, we could then easily control that only if -s MAX_WEBGL_VERSION=21 was passed, then we parse and link in library_webgl21.js. Currently we have an issue that we parse and link in all the src/library_x.js files, even if one does not use them, which is dirty - with MIN/MAX directives on the linking, we could use those to better control which files to link in.

kainino0x · 2018-12-13T19:27:17Z

I agree it would be nice to split up library_gl.js. One major piece of work that I think will eventually be necessary is to rewrite some stuff as library_gl*.c when host bindings are available. (I forget whether I've talked to you about this.)

Host Bindings (with Anyref) would allow WASM to call directly into Web API methods for better performance, which means all of the ES-to-WebGL translation has to happen in C rather than JS. In order to write library_gl.c at all, browser support for Anyref may be necessary.

Also, it's not necessary to move the entire thing wholesale to use host bindings - it's only really going to be important for the more performance critical GL calls. So maybe it's better to keep most of library_gl as JS.

kainino0x · 2018-12-14T01:14:42Z

Another thought on MIN_/MAX_WEBGL_VERSION: I'd prefer not to take the "21" name for WebGL compute just in case there is eventually a 2.1 that isn't exactly the same as webgl2-compute.

How about ALLOW_WEBGL_VERSION=1,2,2compute or 10,20,20compute or webgl1,webgl2,webgl2-compute? Then just assert on invalid combinations of those.

hujiajie · 2018-12-14T01:43:26Z

I like the idea of {MAX,MIN}_WEBGL_VERSION, and I'm seeing if code size regressions can be mitigated with this. I have the same concern with @kainino0x, and some random thoughts:

use OpenGL ES 2.0/3.0/3.1 instead of WebGL 1.0/2.0/2.0 Compute
I suppose WebGL 2.0 Compute will likely be part of the next WebGL revision, if there will be one. WebGL 2.0 Compute should be deprecated if that happens.

kripken · 2018-12-17T19:40:18Z

@kainino0x

One major piece of work that I think will eventually be necessary is to rewrite some stuff as library_gl*.c when host bindings are available.

Definitely, yeah, eventually we will want to migrate most or all of our GL bindings into compiled code, when wasm supports that. We definitely block on anyref for that, and maybe host bindings, but not sure those will be enough.

hujiajie · 2018-12-21T01:12:59Z

The PR has been rebased with the following major changes:

To workaround the GL versioning difficulties, I'm proposing to use a canonical internal representation ("API level"). People may have to map it to the corresponding OpenGL ES or WebGL version mentally though.
Most OpenGL ES 3.1 entry points were added with stub implementation. They remain to be materialized in the future.

Thoughts?

jjxtra · 2019-07-16T22:15:26Z

Will this also include read/write support for compute shaders reading from and writing to textures?

hujiajie · 2019-07-17T01:21:46Z

@jjxtra Yes. You can bind a level of a texture to an image unit with glBindImageTexture() and read/write the image with imageLoad()/imageStore() in your compute shader.

…le way

WebGL 2.0 Compute is an experimental superset of WebGL 2.0, provided by Chrome/Chromium behind the flag `--enable-webgl2-compute-context`. It exposes OpenGL ES 3.1 functionality, notably compute shader, to WebGL via the `webgl2-compute` context.[1][2] The patch adds a new flag `-s USE_WEBGL2_COMPUTE=` to opt-in support for WebGL 2.0 Compute, which is similar to but exclusive with `-s USE_WEBGL2=`. For now, only existing OpenGL ES 3.0 entry points are exposed in this context, and others (those introduced by OpenGL ES 3.1) will be added next. [1] https://www.khronos.org/registry/webgl/specs/latest/2.0-compute/ [2] https://groups.google.com/a/chromium.org/d/topic/blink-dev/bPD47wqY-r8/discussion

The test is expected to work on Windows and Linux with EMTEST_BROWSER="chrome --use-gl=angle --use-angle=gl --use-cmd-decoder=passthrough --enable-webgl2-compute-context". Sadly, the Mesa software renderer is too slow and lacks certain OpenGL extensions for WebGL 2.0 Compute to work, so the test is not enabled in CI.

sbc100 · 2020-01-30T20:16:22Z

The deletion of the incoming branch triggered the automatic closing of this branch. My apologies. This was an unexpected side effect.

Re-opening and re-targeting to master.

stale · 2021-01-31T00:59:08Z

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

kripken reviewed Dec 5, 2018

View reviewed changes

hujiajie force-pushed the webgl2-compute branch from 8e48bd2 to 12d60f8 Compare December 6, 2018 00:40

kripken mentioned this pull request Dec 12, 2018

Preprocessor: Use eval() for good #7651

Merged

juj added the GL label Dec 13, 2018

juj reviewed Dec 13, 2018

View reviewed changes

hujiajie force-pushed the webgl2-compute branch 2 times, most recently from 5e9686d to 2eb13d6 Compare December 20, 2018 11:21

hujiajie force-pushed the webgl2-compute branch from 261822a to 003df2f Compare July 24, 2019 05:32

hujiajie force-pushed the webgl2-compute branch 2 times, most recently from 954cd01 to 2343660 Compare August 14, 2019 02:29

hujiajie force-pushed the webgl2-compute branch 2 times, most recently from 06d2b92 to f61531b Compare August 26, 2019 10:09

hujiajie force-pushed the webgl2-compute branch from f61531b to ee74a7e Compare September 4, 2019 10:51

hujiajie added 11 commits September 23, 2019 15:42

libgl cleanup

a5867d7

do not fill GL context attributes with a hardcoded minor version

483bd45

fold GL.registerContext() into GL.createContext()

791c13f

introducing GL feature level to handle GL contexts in a more extensib…

32b6318

…le way

optimize WebGL code size a little

454d970

add stub and passthrough implementation of GLES 3.1 functions

9109eb0

implement ARB_shader_image_load_store

b68d822

factor out GL uniform table lookup

75a6174

implement ARB_program_interface_query

7edb5c2

hujiajie force-pushed the webgl2-compute branch from ee74a7e to 943b2b1 Compare September 24, 2019 10:44

juj mentioned this pull request Nov 28, 2019

Remove supportsWebGL2EntryPoints #9919

Merged

juj mentioned this pull request Dec 12, 2019

MAX_WEBGL_VERSION #10020

Merged

sbc100 closed this Jan 30, 2020

sbc100 reopened this Jan 30, 2020

sbc100 changed the base branch from incoming to master January 30, 2020 20:16

nickshinpho mentioned this pull request Jun 16, 2020

4.25? UnrealEngineHTML5/Documentation#27

Open

stale bot added the wontfix label Jan 31, 2021

kainino0x closed this Feb 2, 2021

		@@ -8,6 +8,58 @@

		//"use strict";

		var makePPEnum = (function() {

Hello, WebGL 2.0 Compute #7612

Hello, WebGL 2.0 Compute #7612

Conversation

hujiajie commented Dec 5, 2018 • edited

hujiajie commented Dec 5, 2018

hujiajie commented Dec 5, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kainino0x Dec 6, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kripken commented Dec 5, 2018

hujiajie commented Dec 6, 2018

kainino0x commented Dec 6, 2018

kenrussell commented Dec 12, 2018

kripken commented Dec 13, 2018

hujiajie commented Dec 13, 2018

juj commented Dec 13, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kripken Feb 28, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

juj commented Dec 13, 2018

kainino0x commented Dec 13, 2018

kainino0x commented Dec 14, 2018

hujiajie commented Dec 14, 2018

kripken commented Dec 17, 2018

hujiajie commented Dec 21, 2018

jjxtra commented Jul 16, 2019 • edited

hujiajie commented Jul 17, 2019

sbc100 commented Jan 30, 2020

stale bot commented Jan 31, 2021

hujiajie commented Dec 5, 2018 •

edited

hujiajie commented Dec 5, 2018 •

edited

kainino0x Dec 6, 2018 •

edited

kripken Feb 28, 2019 •

edited

jjxtra commented Jul 16, 2019 •

edited