WGPU.NET icon indicating copy to clipboard operation
WGPU.NET copied to clipboard

MacOS surface creation error

Open Hugo4IT opened this issue 2 years ago • 3 comments

Hi :)

I'm trying to create a surface for WGPU on a mac:

// Earlier in the code
Glfw _glfw = Glfw.GetApi();

unsafe
{
    _glfw.WindowHint(WindowHintBool.Resizable, false);
    _glfw.WindowHint(WindowHintClientApi.ClientApi, ClientApi.NoApi);
    _window = _glfw.CreateWindow(settings.Width, settings.Height, "Window Title", null, null);

    if (_window == null)
        throw new Exception("Failed to create a window");
}

// Creating the window
GlfwNativeWindow native = new(_glfw, _window);
instance.CreateSurfaceFromMetalLayer(native.Cocoa!.Value);

just like in the example and it gives the error

thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
  left: `false`,
 right: `true`', /Users/runner/.cargo/git/checkouts/wgpu-53e70f8674b08dd4/628a25e/wgpu-hal/src/metal/surface.rs:96:9
stack backtrace:
   0:        0x1270e7bf8 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h7f563e99e08996c8
   1:        0x1270ff22c - core::fmt::write::h828d1a1d9994c0d4
   2:        0x1270e5cf4 - std::io::Write::write_fmt::h5f89acb1837ba600
   3:        0x1270e7a0c - std::sys_common::backtrace::print::h840392abbac6ee51
   4:        0x1270e8cb4 - std::panicking::default_hook::{{closure}}::h4759ed42ee25f714
   5:        0x1270e8a0c - std::panicking::default_hook::h0e3a71e8a2850720
   6:        0x1270e92f0 - std::panicking::rust_panic_with_hook::h7210718e7f3b5517
   7:        0x1270e9100 - std::panicking::begin_panic_handler::{{closure}}::h783370b8bddac8b4
   8:        0x1270e8060 - std::sys_common::backtrace::__rust_end_short_backtrace::h33a0191324141f1f
   9:        0x1270e8e54 - _rust_begin_unwind
  10:        0x12711fae4 - core::panicking::panic_fmt::h8c7962154a272fe6
  11:        0x1270fd304 - core::panicking::assert_failed_inner::hfc6afabce53d8387
  12:        0x12710e140 - core::panicking::assert_failed::hb9b4375de7f0a30a
  13:        0x126dcc614 - wgpu_hal::metal::surface::<impl wgpu_hal::metal::Surface>::from_layer::h2fd9fe1c7207aa5b
  14:        0x126dcef54 - wgpu_hal::metal::Instance::create_surface_from_layer::h6b2ec2ffa1aa9ad9
  15:        0x126ac6358 - wgpu_core::instance::<impl wgpu_core::hub::Global<G>>::instance_create_surface_metal::{{closure}}::h134f83a8b2b532f9
  16:        0x126beb8a0 - core::option::Option<T>::map::h380bc1f5713ebcef
  17:        0x126b23988 - wgpu_core::instance::<impl wgpu_core::hub::Global<G>>::instance_create_surface_metal::hb40418e2f49952bb
  18:        0x126c95f2c - _wgpuInstanceCreateSurface
fatal runtime error: failed to initiate panic, error 5

So I looked at the piece of code that's causing the issue

pub unsafe fn from_layer(layer: &mtl::MetalLayerRef) -> Self {
    let class = class!(CAMetalLayer);
    let proper_kind: BOOL = msg_send![layer, isKindOfClass: class];
    assert_eq!(proper_kind, YES);      // <-- Error
    Self::new(None, layer.to_owned())
}

I thought maybe I was doing something wrong so I tried WGPU.Tests (the one in this repo) instead but I get the same error. I suspect it might be something to do with Metal and Cocoa not being the same thing but I'm not very familiar with Apple-specific development and online articles seem to intertwine the two. Even the winit crate uses cocoa and metal handles as the same thing.

I have no idea how to fix this, do you have any idea of what could be wrong here?

Hugo4IT avatar Jan 17 '23 14:01 Hugo4IT

Hmm... Out of all the OSes out there, I'm the least familiar with macOS. As far as I know, Cocoa is the name for the API used to actually build and construct apps on Apple systems, while Metal is the actual graphics API that you need to use (either directly or indirectly) to access your gpu.

That's a strange problem.. as far as I know, passing in a handle to Cocoa should work fine. This might be a bug with wgpu_hal, but I'm not sure. Can you write a basic Rust version of your code that initializes a Cocoa window with glfw and seeing if the issue persists? If it doesn't, we'll have to look into what might be causing this on our side.

Trivaxy avatar Jan 18 '23 20:01 Trivaxy

I think the problem might be that wgpu_hal needs both the NSWindow and the NSView but GLFW has not added glfwGetCocoaView yet. Normally you would retrieve the view using obj-C but that's of course not possible with this

Hugo4IT avatar Jan 19 '23 10:01 Hugo4IT

There’s an extension to glfw by @eliemichel that you would probably need. https://github.com/eliemichel/glfw3webgpu

GLFW is for OpenGL and Vulkan, not metal so it has to be shimmed. For SDL2, you can provide a hint for metal driver to have an *NSView with a CA::MetalLayer.

Silk.NET has a work around for MacOS for Their WebGPU bindings that will add a MetalLayer to the view. It’s pretty straightforward with the correct extern calls and handles.ObjectiveC’s Bool8 is a bit of a Jobs-ism. Is it true? Is it false? Is it ushort_t?

gabereiser avatar Oct 15 '23 19:10 gabereiser