hexops / mach Goto Github PK
View Code? Open in Web Editor NEWzig game engine & graphics toolkit
Home Page: https://machengine.org
License: Other
zig game engine & graphics toolkit
Home Page: https://machengine.org
License: Other
Building the gpu
library in this repo currently requires a version of Zig with ziglang/zig#10096 built in, this issue is for me to periodically check in on that PR and make sure it lands in master
/ future releases of Zig
Step 1 is probably getting mach/gpu
(Dawn, specifically) compiling for iOS.
Then we'll need something like the iOS support mentioned in https://zigmonthly.org/letters/2021/august/ to actually build an iOS binary that we can use.
Probably also chat with @MasterQ32 because he's mentioned wanting to do similar stuff in the past and might get to it before me / have insight I don't have yet.
Lastly will be building an "app" abstraction on top of iOS+Android+Web+GLFW APIs for getting a WebGPU window.
Reported by @alichraghi in #75 (comment)
we will need to add the right apt packages to the fetch.sh script here so our SDK has the headers/libs so we can cross compile for Wayland. https://github.com/hexops/sdk-linux-x86_64
It is worth noting that it may be worth waiting until GLFW's Wayland backend (which today is still very immature I think) improves, e.g. in the next version of GLFW there will be support for choosing between X11 and Wayland backends at runtime and so we should begin building for both by default. glfw/glfw#1958
Look into the best way to approach Android support. Maybe something like a Zig port of https://github.com/brackeen/glfm initially.
Hey @slimsag,
When building the test from the root directory for MacOS on Linux...if I just hit 'enter' to accept the seeming 'Y' default for the MacOS SDK install question from build.zig:336, then I get an integer overflow error and stack trace from zig. Simple fix, I suppose, but I wasn't sure if you wanted to force a user to actually type some answer there for legal reasons, so I will leave it up to you. I didn't test on Windows
The Mach system SDKs should include what is necessary for mach-glfw to cross-compile when using Vulkan and OpenGL. This likely just requires including the right libraries etc. in the system SDKs. Currently included is:
This work will be easy to reuse for anybody wishing to cross-compile / build their own OpenGL/Vulkan code in Zig as well. See https://github.com/hexops/mach/blob/main/glfw/system_sdk.zig
Other things that I've heard from the incredible @Snektron regarding Vulkan cross compilation:
By the way, i can let you on in on a secret, and that is if you wish to impress andrew you can make a completely static linux binary by integrating the amdvlk stack directly
I also have GenerateStep.initFromSdk [in vulkan-zig] which can help you fetch vk.xml, "which might also be interesting to know for your system sdk setup
Need a CI pipeline to test building from M1 mac.
Note: GitHub actions doesn't support this yet, actions/runner-images#2187 - but I may be able to set up the M1 mac I bought for developing Mach a few days ago as an actions runner. Need to look into how hard this is to set up.
Same as #49 but for OpenGL
It's returned by public APIs (glfw.Window.getSize
etc), so it's inconvenient to have the type be private.
glfwGetInstanceProcAddress is used in zig-vulkan to gather all function addresses required for the requested vkInstance. Here is a generated code example:
// v--- Loader here is glfwGetInstanceProcAddress
pub fn load(loader: anytype) !Self {
var self: Self = undefined;
inline for (std.meta.fields(Dispatch)) |field| {
const name = @ptrCast([*:0]const u8, field.name ++ "\x00");
const cmd_ptr = loader(.null_handle, name) orelse return error.CommandLoadFailure;
@field(self.dispatch, field.name) = @ptrCast(field.field_type, cmd_ptr);
}
return self;
}
In the definition of glfw.getInstanceProcAddress there are two major issues.
vulkan_call_conv
which is defined as:pub const vulkan_call_conv: std.builtin.CallingConvention = if (builtin.os.tag == .windows and builtin.cpu.arch == .i386)
.Stdcall
else if (builtin.abi == .android and (builtin.cpu.arch.isARM() or builtin.cpu.arch.isThumb()) and std.Target.arm.featureSetHas(builtin.cpu.features, .has_v7) and builtin.cpu.arch.ptrBitWidth() == 32)
// On Android 32-bit ARM targets, Vulkan functions use the "hardfloat"
// calling convention, i.e. float parameters are passed in registers. This
// is true even if the rest of the application passes floats on the stack,
// as it does by default when compiling for the armeabi-v7a NDK ABI.
.AAPCSVFP
else
.C;
I'm unsure how this should be resolved, but two suggestions are:
ABI = enum { Preserved, NotPreserved }
where based on input enum it returns either current implementation or a true to ABI functionThe way the enums are set up right now is very C-like, should clean this up.
Also consider #27 (comment)
Meta issue related to #21
Currently not possible due to GitHub actions not having M1-based runners: actions/runner-images#2187
Considering getting an M1 device for this.
gpu-dawn
for Windowszig build
systemgpu-dawn/build.zig
required for Windows buildssystem_sdk.zig
for use in mach/gpu-dawn
main
of our fork,
windows.ui.*
headers and fix other issues building with Zig
In the original draft of #92, I added an off-the-cuff change to de-normalize error sets. As suggested by @slimsag, I'm opening an issue to discuss this change (and whether it's beneficial enough to consider adding).
Currently, we have normalized errors, adhering to the general possibility imposed by GLFW of (almost) any function returning (or rather "setting") any of the errors specified by the library. But it is important to note that GLFW does obviously specify, for each function, its "possible" error set, and according to the maintainer of GLFW, this documentation is "generally accurate" (paraphrased).
A consideration here is ABI stability: with a normalized error set, that's (almost universally) a guarantee, whilst with denormalized error sets, that's essentially impossible unless we were to freeze the GLFW version.
The other consideration here is how "comfortable" the API is: while a comment describing which errors you might encounter is alright, it is a departure from the error handling philosophy of Zig, and much more akin to C (which is what GLFW aims to cater to). Denormalized errors would slightly increase maintenance, but it would vastly improve readability, given that the errors the user would have to handle would be in the function's signature, and makes it such that a compilation error will be emitted if the user tries to catch an error which the function can't emit.
As well, another positive of denormalized errors would be behaviour-documentation parity. If GLFW changes the behaviour of one of their functions, and adds a possible error to a function, then we'll catch unreachable
on that prong, and be able to make a PR upstream to update their docs. Net positive.
I am in favour of denormalized errors.
Today, we have special build logic in https://github.com/hexops/mach/blob/main/glfw/build.zig which:
git clone
s the relevant system SDK repos https://github.com/hexops/sdk-macos-11.3 and https://github.com/hexops/sdk-linux-x86_64 needed to cross-compile GLFWThis logic is useful outside of just our GLFW bindings, though. For example, it is useful to use this for cross-compiling Google's Dawn WebGPU implementation.
It would also be useful to be able to use this logic outside of Mach entirely, for example to cross compile SDL applications @MasterQ32 ikskuh/SDL.zig#8 - or maybe for @Avokadoen to cross-compile https://github.com/Avokadoen/zig_vulkan perhaps
Idea: Move this logic into a new system_sdk
library, so that one can easily import / benefit from this logic.
Challenge: I don't think these SDKs will always include all system libraries, for example the Linux one picks a very specific set of packages - just those required to build Mach. And it would be nice to slim down the MacOS one even further (currently ~164M). Additionally, it's possible that the versions Mach uses are not what others want, or may change over time. So one important thing here will be making it so that people can very easily fork the SDK repos to modify which system libraries are included, and use their fork if preferred - although probably it'll just work fine in most cases.
Question: Does anyone actually want this? Does this sound useful?
as suggested in #49 (comment)
Setting sysroot
on the builder means that anything not found in our system SDKs cannot be included/linked against. That is very important to avoid.
Better to just set the right include paths, lib include dirs, etc.
After updating to latest Zig master #107 we find an intriguing failure when cross compiling x86_64-macos -> aarch64-macos.
Notably, linux/windows -> aarch64-macos do not fail.
https://github.com/hexops/mach/runs/4339864442?check_suite_focus=true
const std = @import("std");
const glfw = @import("glfw");
const mem = std.mem;
fn printKey(window: glfw.Window, key: glfw.Key, scancode: isize, action: glfw.Action, mods: glfw.Mods) void {
_ = window;
_ = scancode;
_ = action;
_ = mods;
std.debug.print("{s}\n", .{key});
}
pub fn main() !void {
try glfw.init();
defer glfw.terminate();
try glfw.Window.hint(glfw.Window.Hint.context_version_major, 4);
try glfw.Window.hint(glfw.Window.Hint.context_version_minor, 5);
const window = try glfw.Window.create(640, 480, "Hello, mach-glfw!", null, null);
defer window.destroy();
try glfw.makeContextCurrent(window);
window.setKeyCallback(printKey);
while (!window.shouldClose()) {
try window.swapBuffers();
try glfw.pollEvents();
}
}
while the above code running, if you press a keyboard key that will crash with this messsage:
Illegal instruction at address 0x26832c
lib/glfw/upstream/glfw/src/x11_window.c:0:0: 0x26832c in _glfwPlatformPollEvents (/home/ali/dev/kizi/lib/glfw/upstream/glfw/src/x11_window.c)
lib/glfw/upstream/glfw/src/window.c:1072:5: 0x274e74 in glfwPollEvents (/home/ali/dev/kizi/lib/glfw/upstream/glfw/src/window.c)
_glfwPlatformPollEvents();
^
/home/ali/dev/kizi/lib/glfw/src/main.zig:189:21: 0x22b4fd in main (kizi)
c.glfwPollEvents();
glfw.link
currently from a project adds C sources to the compilation step, rather than linking an intermediate library, and so if you're using it from you're own project with C/C++ code compilation can be slower.
We should default to emitting a static lib, and making glfw.link
link to that.
Inital issue was filed in the vulkan example as I though it was a bug in that code and can be found here
The following will panic in release (but not in debug):
const vk_proc = @ptrCast(fn(instance: vk.Instance, procname: [*:0]const u8) vk.PfnVoidFunction, glfw.getInstanceProcAddress);
self.vkb = try BaseDispatch.load(vk_proc);
replacing the following code in mach-glfw resolves the issue:
vulkan.zig
pub fn getInstanceProcAddress(vk_instance: ?*opaque {}, proc_name: [*:0]const u8) callconv(.C) ?VKProc {
const proc_address = c.glfwGetInstanceProcAddress(if (vk_instance) |v| @ptrCast(c.VkInstance, v) else null, proc_name);
getError() catch |err| @panic(@errorName(err));
if (proc_address) |addr| return addr;
return null;
}
with
pub const getInstanceProcAddress = c.glfwGetInstanceProcAddress;
glfws order dependent API design makes sense according to glfw implementation, but is quite silly from a glfw user perspective. I'm confident we can improve the API (hopefully without deviating too much from the C API)
My previous suggestion did not turn out well. Now, vulkan is a very big API, but one thing that I realized is that the design of the API makes it impossible to call functions in the wrong order by forcing you to instantiate an vkInstance
that you then can call functions from. This is again used for later concepts in Vulkan. This concept can be used in the glfw API too!
If init expose all functions that require init through a returned struct, then we can make it impossible to end up with the init error scenario, and this pattern can be used for other similar order dependent function (if there are any)
const glfw_entry = @import("glfw");
pub fn main() !void {
const glfw = try glfw_entry.init(); // use returned API struct
defer glfw.terminate();
// Create our window
const window = try glfw.Window.create(640, 480, "Hello, mach-glfw!", null, null);
defer window.destroy();
// Wait for the user to close the window.
while (!window.shouldClose()) {
glfw.pollEvents();
}
}
Probably on all window managers, maybe on Windows too?
In my case xfce4 (it fails on my Ubuntu based distro called Linux Lite and the Garuda/Arch distro).
I can reproduce at least on Ubuntu 20.04 vanilla.
zig build test -Dtarget=x86_64-macos
fails on Windows with error: Unexpected
when ran from a Windows host OS.
Maybe an issue in final linking? Maybe it's trying to run the Mac binary? Needs investigation
Before any work is done to progress #96, I think it wise to first mop up the errors we can potentially get rid of; that's already done for the now defunct Error.InvalidEnum
, but that remains to be done for Error.InvalidValue
.
This issue can serve to track discussion on that effort, but the main reason I'm opening this is because I've hit a roadblock, and would like to hear some feedback: how to deal with Joystick.updateGamepadMappings
?
The GLFW call does some parsing of the passed string, and can set 'InvalidValue' if it encounters anythign unexpected, which makes preventing this error condition quite a bit more complex.
One option is to try and mimic GLFW's parsing to pre-emptively assert that the format is wrong, and perhaps deliver a useful error message to inform the caller of what's gone wrong; the other option is to simply leave the Error.InvalidValue
code for this function, and allow it to be unique to it, and any other functions that may do parsing that we can't pre-empt in a maintainable fashion, which, while it doesn't allow us to eliminate the error altogether as hoped, would still be more or less made okay by error denormalization.
general issue for tracking this + notes related to it
We should also do what this issue proposed for
glfw.Init
, as there are init hints for GLFW (and potentially one other type of hint? I forget off the top of my head)
Originally posted by @slimsag in #65 (comment)
Latest Zig master has several fixes for macOS framework linking which means some very awkward workaround behavior we had in place to avoid some linker issues is now fixed, and master
no longer builds:
warning(link): unable to resolve dependency /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
warning(link): unable to resolve dependency /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
error(link): undefined reference to symbol '_CGSetDisplayTransferByTable'
error(link): first referenced in '/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/92047481a1a97318e7889499d8a2924f/libglfw.a(/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/c41a8e5da0f2f5ed783557aa4cfa1679/cocoa_monitor.o)'
error(link): undefined reference to symbol '_CGReleaseDisplayFadeReservation'
error(link): first referenced in '/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/92047481a1a97318e7889499d8a2924f/libglfw.a(/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/c41a8e5da0f2f5ed783557aa4cfa1679/cocoa_monitor.o)'
error(link): undefined reference to symbol '_CGOpenGLDisplayMaskToDisplayID'
error(link): first referenced in '/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/92047481a1a97318e7889499d8a2924f/libglfw.a(/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/c41a8e5da0f2f5ed783557aa4cfa1679/cocoa_monitor.o)'
error(link): undefined reference to symbol '_CGGetOnlineDisplayList'
error(link): first referenced in '/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/92047481a1a97318e7889499d8a2924f/libglfw.a(/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/c41a8e5da0f2f5ed783557aa4cfa1679/cocoa_monitor.o)'
error(link): undefined reference to symbol '_CGGetDisplayTransferByTable'
error(link): first referenced in '/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/92047481a1a97318e7889499d8a2924f/libglfw.a(/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/c41a8e5da0f2f5ed783557aa4cfa1679/cocoa_monitor.o)'
error(link): undefined reference to symbol '_CGDisplayVendorNumber'
error(link): first referenced in '/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/92047481a1a97318e7889499d8a2924f/libglfw.a(/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/c41a8e5da0f2f5ed783557aa4cfa1679/cocoa_monitor.o)'
error(link): undefined reference to symbol '_CGDisplayUnitNumber'
error(link): first referenced in '/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/92047481a1a97318e7889499d8a2924f/libglfw.a(/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/c41a8e5da0f2f5ed783557aa4cfa1679/cocoa_monitor.o)'
error(link): undefined reference to symbol '_CGDisplaySetDisplayMode'
error(link): first referenced in '/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/92047481a1a97318e7889499d8a2924f/libglfw.a(/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/c41a8e5da0f2f5ed783557aa4cfa1679/cocoa_monitor.o)'
error(link): undefined reference to symbol '_CGDisplayScreenSize'
error(link): first referenced in '/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/92047481a1a97318e7889499d8a2924f/libglfw.a(/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/c41a8e5da0f2f5ed783557aa4cfa1679/cocoa_monitor.o)'
We just need to properly link the frameworks now, but doing so will require anyone using mach-glfw be up-to-date with latest Zig master
:
GLFW's C API uses "window hints", which aren't hugely user friendly. In Zig, we can do much better by using an "options" struct with default values. My own GLFW wrapper does this for GLFW's window creation, which makes the API much nicer in my opinion.
It could be argued this deviates too far from the C API, but at the same time it doesn't really change much - just combines a few function calls into one, making the API use Zig idioms. I think of it similarly to error handling.
Here's an example of how window creation could look using an options struct:
const window = try glfw.Window.create(640, 480, "Hello, mach-glfw!", .{
.monitor = monitor,
.context_version_major = 4,
.context_version_minor = 5,
.opengl_profile = .core,
});
Since ziglang/zig#10215 Zig will ship versioned libc headers and allow specifying the following target triples for macOS:
* supported triples: * x86_64-macos.10 (Catalina) * x86_64-macos.11 (Big Sur) * x86_64-macos.12 (Monterey) * aarch64-macos.11 (Big Sur) * aarch64-macos.12 (Monterey)
We should reflect this change by:
-macos.12
, have system_sdk.zig
detect that and use the new https://github.com/hexops/sdk-macos-12.0This would give us a truly nice, cross-platform, seamless graphics API across browsers, mobile and desktop via Vulkan, Metal, and OpenGL as fallback.
Use the same Zig API for:
This is also the only truly cross-platform graphics API being blessed by major vendors (e.g. Apple) which leads me to believe it has a real shot long-term at displacing the tried and true Vulkan+Metal+OpenGL combo. And even if it doesn't, there has been a massive undertaking to offer a unified API of that Vulkan+Metal+OpenGL combo in forming WebGPU that very few will be able to effectively beat in the general case (e.g. I think we can effectively beat Godot's, potentially Unity and Unreal's, graphics API abstractions using WebGPU.)
Set up a GitHub action or something that periodically runs the (currently manual) process to sync sub-repositories:
./dev/push-subrepos.sh
Also we should remove ./dev/pull-subrepos.sh
now that it is often ineffective (and we don't accept PRs to subrepos to avoid the complex merge conflicts that can arise even in simple cases)
please compile minimal example and run
$valgrind --leak-check=full --show-reachable=yes program
Similar to #88 - get mach/gpu
(Dawn) compiling for Android and look at using https://github.com/MasterQ32/ZigAndroidTemplate
Reported by @alichraghi in #75 (comment)
Hello, thanks for making this, and specifically mach-glfw.
After following the instructions over at hexops/mach-glfw,
I'm getting this error message when running zig build
in my project directory:
error: unrecognized file extension of parameter '/Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/cocoa_joystick.m'
glfw...The following command exited with error code 1:
/usr/local/Cellar/zig/0.8.1_1/bin/zig build-lib /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/src/main.zig -cflags -D_GLFW_COCOA -- /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/cocoa_joystick.m /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/cocoa_init.m /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/cocoa_window.m /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/cocoa_time.c /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/cocoa_monitor.m /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/nsgl_context.m /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/posix_thread.c /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/monitor.c /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/init.c /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/vulkan.c /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/input.c /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/osmesa_context.c /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/egl_context.c /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/context.c /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/window.c -lc -lobjc --cache-dir /Users/kai/Desktop/test-zig-glfw/zig-cache --global-cache-dir /Users/kai/.cache/zig --name glfw -I /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/include -I /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/vulkan_headers/include -isystem /Users/kai/Library/Application Support/hexops/sdk-macos-11.3/root/usr/include -L /Users/kai/Library/Application Support/hexops/sdk-macos-11.3/root/usr/lib -F /Users/kai/Library/Application Support/hexops/sdk-macos-11.3/root/System/Library/Frameworks -framework CoreFoundation -framework IOKit -framework Metal -framework AppKit --enable-cache
error: the following build command failed with exit code 1:
/Users/kai/Desktop/test-zig-glfw/zig-cache/o/e9c19e6662dcdc3b60a5c83de2450890/build /usr/local/Cellar/zig/0.8.1_1/bin/zig /Users/kai/Desktop/test-zig-glfw /Users/kai/Desktop/test-zig-glfw/zig-cache /Users/kai/.cache/zig
The build.zig looks like this:
const std = @import("std");
const glfw = @import("libs/mach-glfw/build.zig");
pub fn build(b: *std.build.Builder) void {
const exe = b.addExecutable("test-zig-glfw", "main.zig");
exe.addPackagePath("glfw", "libs/mach-glfw/src/main.zig");
glfw.link(b, exe, .{});
}
Darwin macmini.local 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64
Let me know if you need more information.
Please note that this is the very first time I have ever tried to build anything with zig, so I might have missed something crucial.
glfwWindowHint
can take an enum or GLFW_FALSE
/GLFW_TRUE
, and glfwWindowHintString
takes a string. We should just expose a single glfw.window.hint
Zig API that accepts anytype
and defer to the right underlying GLFW function based on the type.
Even if (*Builder).sysroot
is set to a Mac OS SDK, the latest Zig persistently invokes xcrun
so one must dismiss a number of prompts to install XCode and re-run the relevant Zig build command multiple times before build succeeds.
getSDKPath
here invokes xcrun
internally: https://sourcegraph.com/github.com/ziglang/zig@e02caa7e2909c0ae7f7e8ea1378d78e0469b9ff8/-/blob/src/main.zig?L1724-1737
It would be nice if it didn't, at least when we set sysroot
but perhaps even without(?) so that we could supply the relevant MacOS SDKs ourselves and not have any dependency on XCode.
look into how to make this process nice, a unified app/window creation API, etc.
Look into the best way to approach iOS support. Maybe something like a Zig port of https://github.com/brackeen/glfm initially.
When trying to run hello-triangle
example in the webgpu
folder on dawn
branch on Manjaro, building the project results into the linking error
ld.lld: error: undefined symbol: dawn_native::metal::Connect(dawn_native::InstanceBase*)
>>> referenced by Instance.cpp:142 (libs/dawn/src/dawn_native/Instance.cpp:142)
>>> /home/plony/projects/mach/webgpu/zig-cache/o/24dfbf1398b301943d0ad3e68f08b02d/Instance.o:(dawn_native::InstanceBase::EnsureBackendConnections()) in archive /home/plony/projects/mach/webgpu/zig-cache/o/d73b01ef2cd4093c849a311c52ee6344/libdawn.a
ld.lld: error: undefined symbol: dawn_native::InheritsFromCAMetalLayer(void*)
>>> referenced by Surface.cpp:55 (libs/dawn/src/dawn_native/Surface.cpp:55)
>>> /home/plony/projects/mach/webgpu/zig-cache/o/c8b8335d201d3282f328e370fa662d9a/Surface.o:(dawn_native::ValidateSurfaceDescriptor(dawn_native::InstanceBase const*, dawn_native::SurfaceDescriptor const*)) in archive /home/plony/projects/mach/webgpu/zig-cache/o/d73b01ef2cd4093c849a311c52ee6344/libdawn.a
ld.lld: error: undefined symbol: utils::CreateMetalBinding(GLFWwindow*, WGPUDeviceImpl*)
>>> referenced by BackendBinding.cpp:81 (libs/dawn/src/utils/BackendBinding.cpp:81)
>>> /home/plony/projects/mach/webgpu/zig-cache/o/31f70a29fc699c7d51dfac551e7785b5/BackendBinding.o:(utils::CreateBinding(wgpu::BackendType, GLFWwindow*, WGPUDeviceImpl*)) in archive /home/plony/projects/mach/webgpu/zig-cache/o/d73b01ef2cd4093c849a311c52ee6344/libdawn.a
error: LLDReportedFailure
browsing the Surface.cpp and BackendBinding.cpp resulted in finding out that, preprocessor thinks that DAWN_ENABLE_BACKEND_METAL
is defined somewhere. I tried to delete the local repository and do git clone -b dawn --recursive https://github.com/hexops/mach
but the error still appears
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.