The root dir of our repository has grown quite a lot the past few months.
I'd like to make it more clear where the bulk of the engine lives (`src/`) and
also make it more clear which Mach libraries are consumable as standalone projects.
As for the name of this directory, `libs` was my first choice but there's a bit of
a convention of that being external libraries in Zig projects _today_, while these
are libraries maintained as part of Mach in this repository - not external ones.
We will name this directory `libs`, and if we have a need for external libraries
we will use `external` or `deps` for that directory name. I considered other names
such as `components`, `systems`, `modules` (which are bad as they overlap with
major ECS / engine concepts), and it seems likely the official Zig package manager
will break the convention of using a `libs` dir anyway.
Performed via:
```sh
mkdir libs/
git mv freetype libs/
git mv basisu libs/
git mv gamemode libs/
git mv glfw libs/
git mv gpu libs/
git mv gpu-dawn libs/
git mv sysaudio libs/
git mv sysjs libs/
git mv ecs libs/
```
git-subtree-dir: glfw
git-subtree-mainline: 0d5b853443
git-subtree-split: 572d1144f11b353abdb64fff828b25a4f0fbb7ca
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
git mv ecs libs/
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
This matches the order of context parameters always being first in the Zig stdlib
with e.g. sorting and similar places where a context parameter exists.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
`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>
