New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 877301 link

Starred by 4 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocking:
issue 869569



Sign in to add a comment

Need WebAssembly examples for rendering OpenGL ES (WebGL) from a thread

Project Member Reported by kbr@chromium.org, Aug 24

Issue description

There are a couple of examples in the Emscripten code base which demonstrate rendering using OpenGL ES (via WebGL) from pthreads.

https://github.com/kripken/emscripten/blob/incoming/tests/gl_in_mainthread_after_pthread.cpp
https://github.com/kripken/emscripten/blob/incoming/tests/gl_in_pthread.cpp

Unfortunately, these examples both rely on performing OpenGL ES rendering from multiple threads, which is incompatible with the way OffscreenCanvas works. For this reason, these tests only work with Emscripten's WebGL proxy, and we don't want to rely on that for compiling multithreaded game engines to WebAssembly. Instead, the engine should do all of its OpenGL ES work on a single thread.

A couple of simple examples should be added to the Emscripten SDK which render from pthreads in a way compatible with the use of OffscreenCanvas from workers.

Linking this to Issue 869569, because figuring out exactly how these examples will commit their frames for display is a requirement.

 
Cc: aza...@mozilla.com
Cc: dschuff@chromium.org
Components: Blink>JavaScript>WebAssembly
I opened a PR in emscripten with a test for that, browser.test_webgl_offscreen_canvas_only_in_pthread

https://github.com/kripken/emscripten/pull/7051

It passes in Firefox (with SAB + offscreen canvas enabled) but fails in Chrome (with wasm-threads enabled), the receiveInstance call doesn't get a proper object with exports ("TypeError: Cannot read property 'memory' of undefined"). That happens on other pthreads tests too, so it doesn't look related to anything specific here - is that a known issue?
Cc: gdeepti@chromium.org sbc@chromium.org
For my and others' reference:

The basic Emscripten threading tests needed these browser command line arguments as of a couple of weeks ago (from gdeepti@):
--enable-features=WebAssemblyThreads,SharedArrayBuffer --disable-features=WebAssemblyTrapHandler

and it was necessary to compile at least some of the samples with these flags to get them to run in Chrome:

emcc test_pthread_create.cpp -O0 -s USE_PTHREADS=1 -s PTHREAD_POOL_SIZE=10 -s PROXY_TO_PTHREAD=1 -s WASM=1 -o test_pthread_create.html

Owner: kainino@chromium.org
Status: Started (was: Available)
Taking a look.
No problem loading the demo with
google-chrome-unstable --enable-features=WebAssemblyThreads

However the app itself is failing on this assertion:
    EMSCRIPTEN_RESULT r = emscripten_webgl_commit_frame();
    assert(r == EMSCRIPTEN_RESULT_SUCCESS);

so I'm looking at that.
(Version 70.0.3534.4 (Official Build) dev (64-bit))
Owner: ----
Status: Available (was: Started)
Of course, the fix was just:
google-chrome-unstable --enable-features=WebAssemblyThreads --enable-blink-features=OffscreenCanvasCommit

And with that the demo is working as expected.
Cc: kainino@chromium.org

Sign in to add a comment