Targeting WebGPU from Wasm with wasm_webgpu bindings

[Jukka Jylänki]

Hey all,

Emscripten supports targeting WebGPU out of the box via the
-sUSE_WEBGPU linker flag and a set of WebGPU headers that are provided
by Google autogenerated from the Dawn project.

I have been working on our own set of handwritten interop headers for
WebGPU. We use this interop layer at Unity for prototyping our WebGPU
experiments.

The reason for writing another system header is that we had slightly
different goals than what the current Emscripten WebGPU bindings have.

One of the goals of the Dawn-provided headers is to enable one to also
target other native platforms (Windows/Linux/etc.) with WebGPU by
linking against the Dawn API.

In our case, we only wish to target the web, so wanted an interop
layer tuned specifically for Wasm<->JS interop, hence handwriting a
bindings layer specifically for that task.

This resulted in the imaginatively named wasm_webgpu repository, which
you can find at https://github.com/juj/wasm_webgpu . This enables a
low-level C style API for accessing WebGPU in a browser.

The project has been at a complete enough stage for quite a while now,
and is up to date with the latest WebGPU specification draft at the
time of writing, so I wanted to advertise its existence here, in case
someone else might find it useful to play around with. Bug reports are
welcome!

Cheers,
Jukka

[Floh]

This looks super interesting for cross-platform 3D API wrapper libs like my sokol_gfx.h, where access to WebGPU doesn't actually need to go through the cross-platform webgpu.h header, because linking with a native WebGPU implementation like libdawn or wgpu.rs isn't a primary goal (because when compiled natively, the header will talk directly to Metal, GL or D3D11 instead - although having a native WebGPU implementation is nice during implementation of the backend and for debugging).

If there are some obvious advantages (like the different resource mapping approach) I wonder if it makes sense to put this wrapper into the Emscripten SDK as an alternative to webgpu.h? It's not like the Emscripten include directory isn't already a pretty wild hodgepodge of web API wrappers ;) ...and in my experience at least, the API wrappers which are more closely modelled after their underlying web APIs have been a lot more flexible and useful than the API wrappers which tried to emulate 'native platforms APIs' (like OpenAL, GLFW, SDL etc...).

Cheers and thanks for putting your work on github instead of keeping it inhouse :)

-Floh.

[Jukka Jylänki]

Thanks - hopefully it will serve well.

For now, given that Google already did a great work of developing a
compatible bindings library, I did not want to entertain the idea of
upstreaming this library to one of the Emscripten "system" headers. We
certainly would not want to maintain two different ones side by side
there.

I don't know how many developers will find it valuable to be able to
target WebGPU outside the browser via Dawn, so it is hard for me to
judge which bindings layer is of "better" value. Hence giving way to
the Google-developed one in Emscripten, and developing our own thing
in a separate repo. I know Kai was pondering the idea of what it would
look like to implement the Dawn cross-platform compatibility header on
top of wasm_webgpu implementation, though not sure how much value that
work would be either, given that the current Dawn WebGPU bindings
library already exists in Emscripten.

The old headers for OpenAL, GLFW, SDL1.4, GLEW, X11, EGL are all
something I wish one day we'll be able to remove. They were immensely
useful back in the day when Emscripten was in its infancy setting out
to prove its viability. Now, and especially with the requirements
brought on by SharedArrayBuffer for multithreading, their
implementations don't follow the best practices anymore, so we should
not use their existence as a motivation for adding more into
Emscripten.

Wasm_webgpu is able to live comfortably as a "userspace" library in a
separate repo, with the sole exception of issue
https://github.com/emscripten-core/emscripten/issues/15211 , which is
a problem that we don't have a solution for. I.e. due to #15211
Emscripten system JS library headers are "more powerful" compared to
user-created JS libraries.

> --
> You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/4ce07754-3d10-444a-a42a-c0d8c1da0b80n%40googlegroups.com.