Webgl 2 application compiled with emscripten "-pthread" results in extremely slow rendering on Safari 15.2

[macadev]

emscripten version: 3.1.2

Hi emscripten maintainers, thanks for the work on this incredible project. I am working on a C++ game for the web that I compile using emscripten. I recently ran into a use-case that required threading, so I began modifying my project to compile with thread support via the -pthread flag. These are the flags I used to compile with:

set(CMAKE_CXX_FLAGS "-O3 -s USE_WEBGL2=1 -s FULL_ES3=1 -s USE_GLFW=3 -s WASM=1 -s ALLOW_MEMORY_GROWTH=1 -o index.html --preload-file ${project_resources} --use-preload-plugins -s ASSERTIONS=1")

This is what I switched to in order to enable thread support:

set(CMAKE_CXX_FLAGS "-O3 -s USE_WEBGL2=1 -s FULL_ES3=1 -s USE_GLFW=3 -s WASM=1 -s ALLOW_MEMORY_GROWTH=1 -pthread -o index.html --preload-file ${project_resources} --use-preload-plugins -s ASSERTIONS=1")

This results in a build that runs perfectly fine in Firefox and Chrome, but for some reason in Safari 15.2 (the latest version) it leads to my rendering code taking over 20 seconds to put out a single frame. I don't have any threading code implemented yet - simply compiling the project with -pthread results in the enormous performance penalty.

Before I go and try to create a minimal reproducible build, does anybody have any ideas as to what might lead to this massive performance penalty? Is this a known issue in Safari? I have only found this issue from another person with a similar project that ran into this problem (link).

Thanks for your time.

Sample time it takes to render a frame with a -pthreads build (time obtained via glfwGetTime(), it's in seconds):

RENDERING START 225.98 
RENDERING END 265.033

[kripken]

This sounds like a Safari bug. PThreads support there is fairly recent. But I'm not aware of a bug like that, which sounds very odd...

Perhaps the Safari profiler shows something?

If not, and no one else has ideas, I'd suggest filing an issue on the webkit tracker with a testcase so they can look at it.

[macadev]

@kripken I did find something interesting in the profiler. It looks like uniformMatrix4fv is what's taking an inordinate amount of time:

The webkit bug I linked references the same exact call: https://bugs.webkit.org/show_bug.cgi?id=232662

I tried doing what the issue above suggested. I downgraded to using a 'webgl' canvas context instead of 'webgl2'. I did this using -s GL_PREINITIALIZED_CONTEXT=1 and the following line in my JS:

Module.preinitializedWebGLContext = document.getElementById('canvas').getContext("webgl");

This made the issue go away, but I had to rewrite all my shaders using GLSL 100. My game is running fine now and with threads enabled in Safari.

I was really hoping to be able to write my shaders using GLSL 300 (supported by webgl 2.0) since I use some features not available in GLSL 100 (which is what webgl 1.0 supports). Do you know if it's possible to use a webgl 1.0 context with shaders written using GLSL version 300? I'm asking since the emscripten OpenGL page talks about various emulation features.

Thanks again for the help!

[macadev]

I'm not sure if this refers to exactly the same call I'm doing, but it does indicate that Safari 15.2 does not support "WebGLRenderingContext API: uniformMatrix4fv: WebGL2: SharedArrayBuffer as a parameter"

https://caniuse.com/mdn-api_webglrenderingcontext_uniformmatrix4fv_webgl2_sharedarraybuffer_as_param

I think I might have finally answered my own question.

[kripken]

Do you know if it's possible to use a webgl 1.0 context with shaders written using GLSL version 300?

I don't know myself, but @juj or @kainino0x might.

[kainino0x]

GLSL ES 3.00 is only available in WebGL 2.0 contexts.