search

floooh / sokol-zig

Zig bindings for the sokol headers (https://github.com/floooh/sokol)
zlib License
376 stars 48 forks source link

Building for WGPU backend fails with non-default Zig release modes #86

Closed c1b closed 3 weeks ago

c1b commented 3 weeks ago

This works:

zig build run-shapes -Dtarget=wasm32-emscripten -Dwgpu=true

These all fail: 

zig build run-shapes -Dtarget=wasm32-emscripten -Dwgpu=true --release=small
zig build run-shapes -Dtarget=wasm32-emscripten -Dwgpu=true --release=fast
zig build run-shapes -Dtarget=wasm32-emscripten -Dwgpu=true --release=safe

Here is the error I see in JS console in all failure cases:

Uncaught (in promise) TypeError: Failed to execute 'configure' on 'GPUCanvasContext': Failed to read the 'format' property from 'GPUCanvasConfiguration': Required member is undefined.
    at ta (shapes.js:68:9)
    at shapes.wasm:0x56c9
    at shapes.wasm:0xd42e
    at shapes.js:59:428
    at I (shapes.js:12:234)
    at shapes.js:59:257

I know this issue is several flags deep, but I'm confused by why this would happen. Would love a sanity check if someone can confirm that this is indeed unexpected.

floooh commented 3 weeks ago

Can reproduce, investigating... but for the time being it's better to understand the WebGPU backend as experimental as long as the WebGPU API hasn't stabilized. There's still lots of changes in the WebGPU API and then it can take several months until those changes trickle into the Emscripten WebGPU shim.

floooh commented 3 weeks ago

Ah... right. It's this known issue in the Emscripten SDK:

https://github.com/emscripten-core/emscripten/issues/20415

...basically, the current WebGPU shim in the Emscripten SDK doesn't support the Closure compiler optimization pass.

You can work around for now by adding a .release_use_closure = false, to the options here:

https://github.com/floooh/sokol-zig/blob/fe47d2055d7b86bdcbaf02610109b1f1aa5dfdc1/build.zig#L114-L125

I could add that when specifically building for WebGPU, but since it's clearly a bug in the Emscripten SDK I don't know if that's a good idea (especially considering that the entire WebGPU stuff is still in flux).

The downside of not running the Closure pass is that the output .js file with the Emscripten runtime and web API shims will be larger and isn't as optimized.

c1b commented 3 weeks ago

Of course its you that tracked down and reported this emcc issue months ago.... I bow to your power 🙇