I know you said elsewhere in this thread that you want to focus on a single WebGPU runtime for the moment, but I just want to plug how easy it is to build wgpu even as a submodule of a C++ project. I had a demo integrated into my project in less than an hour of tinkering with CMake.
because the FetchContent cache invalidations would still periodically lead to recompiling which gets quite annoying. When it's just a matter of linking you get few-second builds consistently. The cost is we'll have a bit of hardening around potential ABI bugs but it's ultimately worth it.
We'll work towards wgpu support. There's some sharp edges in the non-overlap w/ dawn which seem most pronounced with the async handling (which is pretty critical), but I don't think anything is a hard blocker.
Comments
I know you said elsewhere in this thread that you want to focus on a single WebGPU runtime for the moment, but I just want to plug how easy it is to build wgpu even as a submodule of a C++ project. I had a demo integrated into my project in less than an hour of tinkering with CMake.
Yes wgpu is a much lighter build and has a lot going for it.
The situation has gotten a lot better for both dawn and wgpu integration in C++ with:
https://github.com/eliemichel/WebGPU-distribution/
Getting a shared library build was a revelation though, credit to:
https://github.com/jspanchu/webgpu-dawn-binaries
because the FetchContent cache invalidations would still periodically lead to recompiling which gets quite annoying. When it's just a matter of linking you get few-second builds consistently. The cost is we'll have a bit of hardening around potential ABI bugs but it's ultimately worth it.
We'll work towards wgpu support. There's some sharp edges in the non-overlap w/ dawn which seem most pronounced with the async handling (which is pretty critical), but I don't think anything is a hard blocker.
WebGPU-distribution is news to me; thanks for the link!