Repository navigation
C++ Wrapper #596
Description
I'd like to propose adding a C++ wrapper to this repository.
Dawn ships webgpu_cpp.h, which has become the de facto standard C++ bindings for WebGPU. That works well if you want to use Dawn's implementation, but if you want to use C++ with a different backend — wasi:webgpu in our case — the only option is to bind directly to the C header. That defeats the purpose of having a standard, implementation-agnostic header, at least for C++ use cases
Emscripten also implements webgpu_cpp.h, so it's already in use across multiple projects and backends, not just Dawn.
Would it make sense to move (or adopt an equivalent of) webgpu_cpp.h into webgpu-headers, so it becomes a standard C++ wrapper that any implementation (Dawn, wgpu-native, wasi:webgpu, etc.) can provide, rather than something tied to a specific implementation?
Activity
kainino0x commentedon Jul 14, 2026
I think C++ bindings should live in a separate project, here's my rationale:
There's at least one other: https://github.com/eliemichel/WebGPU-Cpp
In C++, it's impossible to add methods to a previously-defined class, so C++ bindings would more naturally be maximal, defining bindings to any and all implementations and all their (possibly unstable) extensions and having multiple versions (like both Dawn and eliemichel's bindings do) or use
#ifto enable different parts.Related: Making language bindings portable over different versions of webgpu.h #202
MendyBerger commentedon Jul 15, 2026
A separate repo under this org would be fine, the point is official standing, not this repo specifically.
Some context on why I opened this: big projects like llama.cpp and onnx-runtime write their WebGPU backends against Dawn's
webgpu_cpp.h, so they're stuck on one implementation. I'd like to get them onto backend-agnostic code so they also work on wgpu-native,wasi:webgpu, etc.https://github.com/eliemichel/WebGPU-Cpp shows this is doable, but a project that size isn't going to depend on a single-maintainer repo, however good it is. Dawn's header became the standard because Google ships it. If there were an official wrapper somewhere under webgpu-native, "use the standard bindings instead of Dawn's" becomes a PR I can actually send them. Right now it isn't.
kainino0x commentedon Jul 15, 2026
Makes sense. Unfortunately the amount of maintainer power behind this org is not really any bigger, it has some participation from wgpu and Dawn but no dedicated time from anyone (wgpu-native hasn't even seen much progress in updating to the stabilized webgpu.h). And since Dawn has its own bindings we wouldn't really be contributing to it. Though I definitely want to see there be portable C++ bindings.
Maybe @eliemichel would be interested in making WebGPU-Cpp more official?
MendyBerger commentedon Jul 17, 2026
Not sure how realistic this is, but would Dawn be open to donating
webgpu_cpp.hto the org?It seems like the path of least resistance: the header already has maintainers (Dawn's team, who keep it current with
webgpu.h) and a large existing user base through both Dawn and Emscripten. The maintenance wouldn't change, just where it lives — Dawn consumes it from here like any other implementation would. That sidesteps the maintainer-power problem, since the org isn't taking on work nobody has time for.Compared to other options, this one also has the smallest migration cost for the ecosystem. Projects like llama.cpp and onnx-runtime are already written against
webgpu_cpp.h, so if it lived here they'd get backend-agnostic bindings essentially for free — whereas any new or adopted wrapper asks all of those projects to port.That said, making WebGPU-Cpp more official would be a great outcome too — just wanted to put this on the table as well.
Kangz commentedon Jul 21, 2026
Dawn should be able to produce a C++ header for the subset of
dawn.jsonthat matches the headers in this repo, but Dawn cannot consume C++ headers from this repo because it adds a lot of Dawn-specific extensions. We also cannot make stability guarantees for the C++ headers as we keep tweaking them to make them more ergonomic or safe to use. I also don't know what the mechanisms would be to generate the headers because the code generators live in Dawn and use a JSON file instead of YAML.If it were to happen, I believe we'd need to generate the C++ headers using upstream Dawn's code generator by producing an alternative JSON file for it.
MendyBerger commentedon Aug 19, 2026
Maybe an easier ask would be to add a
webgpu.horwasito the dawn generatorThis should not take a lot of work since it would be more restrictive than all the other options in there.
Something like this
If the dawn maintainers would be open to this, I'm happy to open a PR if outside contributions are allowed.
Kangz commentedon Aug 19, 2026
Dawn can take something like this and put it as part of the generation of the "webgpu_headers" that match the headers here.
Contributing is certainly welcome! https://dawn.googlesource.com/dawn/+/refs/heads/main/CONTRIBUTING.md
Generate and expose upstream-flavored WebGPU C++ headers