aab99b5474
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> |
||
|---|---|---|
| .github | ||
| dev | ||
| ecs | ||
| glfw | ||
| gpu | ||
| gpu-dawn | ||
| src | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| build.zig | ||
| LICENSE | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| README.md | ||
Learn more at hexops.com/mach
Join the conversation
Our community exists on Matrix chat, join in and help build the future of game engines & graphics in Zig!
You can also follow @machengine on Twitter for updates.
⚠️ in-development ⚠️
Under heavy development, not ready for use currently.
Supported platforms
Mach is still incredibly early stages, so far we have support for building from the following OS to the following targets:
| Building for | From macOS x86_64 | From macOS M1/aarch64 | From Linux x86_64 | From Windows x86_64 |
|---|---|---|---|---|
| macOS x86_64 | ✅ | ✅ | ✅ | ✅ |
| macOS M1/aarch64 | ✅ | ✅ | ✅ | ✅ |
| Linux x86_64 | ✅ | ✅ | ✅ | ✅ |
| Windows x86_64 | ✅ | ✅ | ✅ | ✅ |
| iOS | 🏃 | 🏃 | 🏃 | 🏃 |
| Android | 🏃 | 🏃 | 🏃 | 🏃 |
- ✅ Tested and verified via CI.
- ✔️ Should work, not tested via CI yet.
- 🏃 Planned or in progress.
- ⚠️ Implemented, but has known issues (e.g. bugs in Zig.)
Subrepositories / projects
Whether you're interested in using all of Mach, or just some parts of it, you get to choose. Our libraries all aim to have the same zero-fuss installation, cross compilation, and platform support:
- mach-glfw: Ziggified GLFW bindings with 100% API coverage
Contributing
Mach is maintained as a monorepo. When changed are merged to this repository, we use some git fu to pick out the commits to subdirectories and push them ot sub-repositories. For example, commits to the glfw/ directory also get pushed to the separate mach-glfw repository after being merged here.
There are only two requirements:
- Pull requests to sub-repositories must be sent to this monorepo, not to the sub-repository itself - to avoid some annoying merge conflicts that can arise.
- Individual commits may not change multiple sub-repositories at the same time (e.g. a commit to
glfw/cannot also include changes togpu/, to avoid confusion.)