Surface creation on MoltenVK fails due to missing CAMetalLayer with a new winit window

[Ralith]

VK_ERROR_INITIALIZATION_FAILED: vkCreateMacOSSurfaceMVK(): On-screen rendering requires a layer of type CAMetalLayer.

See also gfx-rs/gfx#2838, wherein gfx fixed this error by checking for a CAMetalLayer and constructing one if absent using macos APIs. Presumably we can copy their code. I'm probably not the best person to draft this, as I have no access to macos for testing.

[msiglreith]

Thanks for the report.
There are a few points I would like to change in this regard but I don't have any machine which supports Metal.

• Move towards the VK_EXT_metal_surface extension (mvk extensions are deprecated, ash doesn't have a nice extension layer so far)
• Provide a translation layer from MacOsHandle/IOSHandle to CAMetalLayer

The 2nd point could maybe be done together with gfx-rs? Right now, gfx-hal requires either a ui_view or ns_view from the raw window handle, which might not be the case actually (rust-windowing/raw-window-handle#14)

[msiglreith]

wgpu seems to support the ns_window path at least: gfx-rs/wgpu#462

[Ralith]

If you have a sense for what the code should be, would it make sense to draft a branch so someone with access to a suitable environment can test it and report back?

[msiglreith]

I'm currently extracing the relevant code pieces from gfx sources into https://github.com/norse-rs/raw-window-metal and hoping to move it into the gfx-rs organization afterwards as they have more resources and a larger userbase over there

[Ralith]

Awesome! Does it really make sense for that to be a separate crate, though? It seems like ash-window could subsume gfx's vulkan surface construction across all platforms, unless I'm missing something.

[msiglreith]

The metal and vulkan backend of gfx currently use these code pieces therefore I went with a separate crate.

An open question for me is if handling of resize or hdpi changes is required, which would make it difficult to go with the manual layer allocation. This might require that the user allocates and maintains a CAMetalLayer themself

[Ralith]

The metal and vulkan backend of gfx currently use these code pieces therefore I went with a separate crate.

Ah, that makes sense.

An open question for me is if handling of resize or hdpi changes is required, which would make it difficult to go with the manual layer allocation. This might require that the user allocates and maintains a CAMetalLayer themself

I really want to be able to just plug winit into ash and not have to think about platforms; that's the big win with ash-window so far. I have no idea what constraints there are on the macos side, but I hope there's a way forward that preserves that.

[Friz64]

closed by #9

[msiglreith]

Released in 0.4.1