emscripten-core / emscripten-core/emscripten

Why isn't there a `WebGPU.wasm` module or similar?

Open
#15,710 4 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
27.6k
Forks
3.6k
Avg merge
1d 1h
Merged PRs (30d)
105

Description

One of the major sells of wasm is to be able to instantiate different services with different modules to service different embedders (JS, WASI-compatible runtimes etc.) such that you can create different modules that serve other modules, configured by the host/embedder, or serve the embedder directly.

You can generate wasm from LLVM raw, but the glue code is still needed to interact with JS APIs like WebGPU or WebGL, I want to be clear that I am not suggesting that wasm should have JS APIs available to Wasm inherently.

What I am confused about is why the modularity benefits aren't even available as a premade option with Emscripten. It would seem that the WebGPU or WebGL (etc) APIs should be available as modules to be linked with your application when you instantiate with the WebAssembly JS API, such that if you were to move your wasm module to a different embedder/runtime (such as wasmtime or the like) you would just swap in `webgpu_wasi.wasm` in place of the `webgpu_js.wasm` and library to instantiate it and provide the functions `webgpu.js` or something.

I can understand just swapping out the posix-style APIs for porting jobs, but it seems strange to target OS apis if I am creating a new web-capable, cross-platform application.

The WebGPU API, for instance, changes very often, and uses Dawn's generator to make it all work, shouldn't this just be made an upgradeable wasm module within one's browser application that is linked with your cross-platform/platform non-specific wasm module? Can this functionality be added to Emscripten? (or if it already exists, is there any documentation on this?)

Notably, nothing about doing this would make porting jobs not work, unless there is some objection to having more than one module, which seems to really miss the point of wasm's benefits, or if Emscripten is being sold as a way to not have to worry about JS, ostensibly the number of modules won't matter to the user. (And of course this option could be not only optional, but a different tool altogether which is only optionally used or something to that effect.)

All of the glue code for wasm under `library_webgpu.js` etc is there, but I don't know why this isn't a package or easily usable tool, given the updates will be frequent and regeneration will be required.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.