`webgpu.h` does not expose a method of choosing the GPU backend (vulkan, opengl, opengles, etc.)
at present. The only way to achieve this is to use Dawn's C++ API, which we expose as C shims
under the `machDawnNative*` prefix.
For now, we will use the Dawn adapter creation API so that we can choose between Vulkan/OpenGL/OpenGLES
etc via the `GPU_BACKEND` env var.
In the future, I believe we can do something nicer here. For example, perhaps we extend our `requestAdapter`
method (after all, we do not need to strictly match `webgpu.h`) to take such an option and be Dawn-aware so
that it handles this more seamlessly behind the scenes.
Fixes https://github.com/hexops/mach/issues/192#issuecomment-1080895255
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
Previously we were attempting to turn WebGPU async functions, which are
exposed by `webgpu.h` as callbacks, into Zig async functions.
This in practice turns out harder than expected. For example, `Buffer.mapAsync`
/ `wgpuBufferMapAsync` cannot easily be exposed as a Zig async function for a few
reasons:
1. The callback is merely guaranteed to be called once the buffer's content is ready to
be accessed via `wgpuBufferGetMappedRange` - but there is no strict guarantee about
when that is. It could be 1-3 frames later, in theory, I believe.
2. The non-deterministic timing means that one would wish to poll "has the async function
returned?" but this isn't trivial without our own scheduler.
3. Zig has a fair amount of async rework in the future that is coming, and I imagine it
will be one of the later things that is fully supported by the WebAssembly backend
(but I am speculating) - so it seems wise to punt on this until later.
Instead, we are now retaining async functions as callback-based ones, with a helper in
this case to wait for the callback to be invoked. For `wgpuBufferMapAsync` we will just
have the callback approach.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
