Skip to content

MacOS surface creation error #5

Description

@Hugo4IT

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?

Activity

  1. Trivaxy commented on Jan 18, 2023

    @Trivaxy
    Owner

    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.

  2. Hugo4IT commented on Jan 19, 2023

    @Hugo4IT
    Author

    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

  3. gabereiser commented on Oct 15, 2023

    @gabereiser

    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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions