Emscripten's webgpu.h is behind the standard and Dawn implementations

[orhun-sketchup]

Is it possible to update to a recent version of webgpu_cpp.h?

I am specifically interested in missing templated async functions.

like in the Buffer class.

template <typename F, typename T,
              typename Cb = BufferMapCallback<T>,
              typename CbChar = void (MapAsyncStatus status, const char* message, T userdata),
              typename = std::enable_if_t<std::is_convertible_v<F, Cb*> || std::is_convertible_v<F, CbChar*>>>
Future MapAsync(MapMode mode, size_t offset, size_t size, CallbackMode callbackMode, F callback, T userdata) const;
template <typename L,
              typename Cb = BufferMapCallback<>,
              typename CbChar = std::function<void(MapAsyncStatus status, const char* message)>,
              typename = std::enable_if_t<std::is_convertible_v<L, Cb> || std::is_convertible_v<L, CbChar>>>
Future MapAsync(MapMode mode, size_t offset, size_t size, CallbackMode callbackMode, L callback) const;

[kainino0x]

For the moment we won't be bringing any new changes into Emscripten's WebGPU bindings because we don't want to continuously make breaking changes on every Emscripten release. However we are currently working on an updated fork which lives in Dawn. You can use this fork along with regular Emscripten - it's a big pain right now but it's possible. See:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/dawn/src/emdawnwebgpu/README.md
This sample repo is set up to do this:
https://github.com/kainino0x/webgpu-cross-platform-demo/tree/dawnwasm
You can follow here for updates on the un-forking: https://crbug.com/371024051 (+1 button in the top right)

[ypujante]

@kainino0x Now that you can write contrib ports in Emscripten, wouldn't it make sense to have a contrib.webgpu (or contrib.dawn_webgpu) to do this? That way you are not breaking Emscripten WebGPU binding. You just upgrade the port version (which might contain breaking changes).

You can also have the port not be a contrib port at all meaning it is a port that anybody can use (simply) without being part of Emscripten. Like I did for ImGui. This port file could live in the Dawn project.

I don't know the internals of Dawn or why it was chosen to have an Emscripten fork which lives in Dawn. I am just pointing out that there is a new mechanism (Emscripten ports) that is available...

I am very familiar with Emscripten contrib/external ports, since I am the one who implemented the feature, so don't hesitate to reach out if you need help/guidance...

[kainino0x]

I wasn't aware of emscripten-ports! Regardless of that, we actually just started talking to sbc100 about this topic, we might end up maintaining the bindings as a library outside of emscripten instead. The reason we did it in Emscripten to start was that it relied on a lot of internal things. We need a stableish interface between emscripten and js libraries, and a stableish interface for gen_struct_info.py. But it sounds like we may be able to achieve that!

TBA, and thank you for your offer!

[kainino0x]

FYI: I'm working on updating the code and documentation in Dawn for how to use emdawnwebgpu (our fork). It's much easier with Emscripten 4.0.3+!

https://dawn-review.googlesource.com/c/dawn/+/227335/4/src/emdawnwebgpu/README.md

[sbc100]

At the end of that process should we delete the webgpu support from emscripten? (we can still test it via some kind of vendoring, or add it as a "port")

[ypujante]

I am not sure what is the plan (it is hard to follow this thread and a link to the diff of an upcoming README file change is not really helping) but I hope that no matter the solution, there continues to be an easy way to use WebGPU from Emscripten.

I really don't want to have to clone an external project and use CMake to build WebGPU especially that now Emscripten has support for integrating external projects, not maintained in Emscripten (contrib ports).

I am hoping that Dawn/WebGPU can at the very minimum be offered as a contrib port (and I reiterate what I stated in a previous message, that I am more than happy to provide help and guidance...)

[kainino0x]

I've been working on producing a "packageable" version of emdawnwebgpu that can be easily used by just linking into an emscripten build. Once that's done I should be able to point to updated docs that actually make sense :)

I'll give an update here when that's ready - so I can get help figuring out how this package should be provided to people (I don't know how "ports" work).

[kainino0x]

Those readme changes I linked to have been updated and landed, so there are at least (partial) instructions on how to use emdawnwebgpu:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/dawn/src/emdawnwebgpu/README.md

I'm still working on making pre-packaged releases of emdawnwebgpu. Basically what that's going to look like is something like:

├── CMakeLists.txt
├── LICENSE
├── include
│   ├── dawn
│   │   └── webgpu_cpp_print.h
│   └── webgpu
│       ├── webgpu.h
│       ├── webgpu_cpp.h
│       ├── webgpu_cpp_chained_struct.h
│       └── webgpu_enum_class_bitmasks.h
├── library_webgpu.js
├── library_webgpu_enum_tables.js
├── library_webgpu_generated_sig_info.js
├── webgpu-externs.js
├── webgpu.cpp
├── webgpu_generated_struct_info32.json
└── webgpu_generated_struct_info64.json

where CMakeLists.txt includes all of the flags needed to make that work.

For maintenance reasons it seems easier for this to be totally separate from Emscripten, rather than a port. A bunch of these files are generated (not checked into Dawn) so it's not possible to point directly at Dawn's source.

But I'm curious if you think it would be better to add it to the ports. It will be easier to install, but it seems you will only be able to use the version pinned in Emscripten? At least, the contrib ports that exist now seem to pin a version.

[ypujante]

@kainino0x I still think that having it as a port would still be very beneficial: the README that you published is quite involved with lots of steps, including complicated instructions to download and build Dawn. Using the port would be as simple as emcc --use-port=contrib.dawn and that's it for the instructions... hard to be simpler...

The fact that the Dawn version is pinned to Emscripten version is not really a problem. This is how SDL, GLFW, (etc...) ports work. Upgrading Emscripten for the new version of Dawn now becomes trivial. If you want to use a different version you can always copy the port file and use it directly since now Emscripten allow non built-in ports.

You mention that there are files that are generated and not checked in into Dawn. I do not know how Dawn gets released (when there is a new version), but if you could automatically publish a zip file containing all the necessary files to build Dawn for Emscripten (both generated and checked in) that would be the best approach. Maybe this is what you are talking about when you say: I'm still working on making pre-packaged releases of emdawnwebgp

I am doing exactly this for the GLFW port:

and then in the port, the downloaded artifact is simply:

TAG = '3.4.0.20250305'
HASH = 'd5d1496cf1e05a640c182584a09ed0b43c8d6c42386513e5c2b1e05a2289854a0a0abe085e0a8b64c3a484836a8e63dc5ddb683ce4d2899fccbbf89536d58ee1'
ZIP_URL = f'https://github.com/pongasoft/emscripten-glfw/releases/download/v{TAG}/emscripten-glfw3-{TAG}.zip'

I will spend some time looking at a first pass at the Emscripten Dawn port if I can follow your instructions.

[sbc100]

We certainly want emscripten users to be able to use WebGPU APIs with as little friction as possible.

There are various ways we could achieve that without having to maintain emdawn directly in the emscirpten tree. I think a "port" is likely the best option. We might also want to consider using a git submodule, but I'm not sure that would be any better. I think having emscripten default to particular pinned version is fine (good even) as long as we document some way to experiment to non-pinned version too.

[kainino0x]

Ports do sound extremely convenient. As long as there is some easy way to use a non-pinned version, I'm OK with having a pinned default. The bindings are definitely still buggy so for the near-term future, people will commonly need the latest version, ideally without having to upgrade their whole toolchain.

[kainino0x]

I do not know how Dawn gets released (when there is a new version), but if you could automatically publish a zip file containing all the necessary files to build Dawn for Emscripten (both generated and checked in) that would be the best approach. Maybe this is what you are talking about when you say: I'm still working on making pre-packaged releases of emdawnwebgpu

Dawn doesn't have any releases (pre-built or otherwise), but since we need to provide pre-built files for emdawnwebgpu, yes, that's my plan - upload packages like the one described above, either as zips on the github releases page, or in some git repository.

[ypujante]

Dawn doesn't have any releases (pre-built or otherwise), but since we need to provide pre-built files for emdawnwebgpu, yes, that's my plan - upload packages like the one described above, either as zips on the github releases page, or in some git repository.

Awesome. When you do that let me know and I can take a pass at writing the (contrib?) port for Emscripten or help @sbc100 if he would prefer to do it himself. I can think of a couple of ways on how to allow changing the pinned version.

[sbc100]

@kainino0x and I had a quick VC meeting today and it sounds like a port is going to be the way to go. They might even just go with an external port (e.g: --use-port=/path/to/emdawn_files/emscripten_port.py).

[krauthaufen]

Any updates on that?
I‘m building a dotnet wrapper around dawn and would love to see it run in the browser too. I did the same with WebGL a few years ago and have a running pipeline for auto-generating all my stuff. Sadly the dotnet environment pins me to emscripten 3.0.56 for now, so all cutting edge things won‘t work for me.

Any hints how to make this work?

[sbc100]

The plan is for emdawn to maintain an out-of-tree emscripten port. The goal is to make this trivial/easy to use from emscripten directly, but it almost certainly will not work with old emscripten version like 3.0.56.

I would advice you to petition the dotnet folks to update their emscripten version.

[krauthaufen]

Thanks for the reply. I just found that dotnet is actually using 3.1.56 where ports should be working. I‘d be happy to help with testing things when you have the port ready.

[sbc100]

3.1.56 is still a year old. I would imagine that emdawn will require a current (e.g. 4.0.0+) version.. but that still remains to be seen.