Update VulkanHelper to support surface creation on macOS #3
Conversation
There are two major parts in this commit: * basic Objective-C runtime layer; * `SimpleCocoaWindow` that makes use of it. The former one relies on Objective-C runtime (`libobjc`) methods to perform a few basic operations. The most important ones are `objc_msgSend` bindings that differ in number of input arguments and return value yet invoke the same function exported by `libobjc`. See more on runtime in Apple documentation: https://developer.apple.com/documentation/objectivec/objective-c_runtime `SimpleCocoaWindow` invokes `Cocoa` object methods to acquire Metal layer and show/hide window. Note that it uses `AppKit` types such as `NSWindow` or `NSView` and thus is macOS-specific. iOS devices use `UIKit` (`Cocoa Touch`) and thus initialisation should be done by sending messages to `UIView`.
Uses MoltenVk implementation of Vulkan API, see: https://github.com/KhronosGroup/MoltenVK Supports both deprecated `VK_MVK_macos_surface` and actual `VK_EXT_metal_surface` extensions to create Vulkan surface. Also slightly refactors helper to allow specification of multiple dynamic libraries to probe.
|
I think it's probably a better idea to pass an NSView as the "window" for this one. I've messed with this and GTK, and it seems that our approach for trying to pull an embedded window out of a DrawingArea doesn't work. What did work is creating an NSView, adding it as a child and positioning it manually to match the GTK component (recaluclates when component moves). I can imagine a similar approach working for Avalonia. Were you able to get embedded window creation working on the GTK side? As for general stuff, code comments are generally correctly capitalized and well punctuated, like |
Can you elaborate on what do you mean by embedded window? If you can reference a simple GTK# project that has embedded window you are talking about, I can test it later this week (the troublesome part of Vulkan initialisation boilerplate is already done, so it is just a matter of copy-pasting and passing window or view handle to verify code in PR).
Sure, will fix it. |
- Changes comments punctuation to the suggested. - Allows to pass either `NSView` or `NSWindow` into SimpleCocoaWindow constructor.
|
Sorry for the unusually long delay, the example project would be Ryujinx. I don't really have a simpler example on hand. |
|
Since 21b6f4b is a thing now... It might still be a good idea to port use the more fleshed out ObjectiveC class in this PR rather than the rather simple MacOS one for interop. Supporting generating the layer from a window could also be useful. |
|
Sorry, a bit busy week. Will catch up with comments later. I get your concern now. I am not sure that GTK widgets are mapped to per-widget |
I may have forgot about that PR and made some changes on 21b6f4b while working on my GBA emu 😅 Could you maybe rebase or maybe close and split the changes? I think the surface creation split in the VulkanHelper class could be nice to have. I still am not to sure with the design of SimpleMetalWindow I made, for now all CAMetalLayer creation need to be handled externally. |
Overview
This PR updates
VulkanHelperclass to support creation of surfaces on macOS and introducesSimpleCocoaWindowto work withNSWindow.VulkanHelperchanges:libvulkan;CreateWindowSurface()method to split it into a set of platform specific methods and thus reduce complexity a bit.SimpleCocoaWindow:NSViewandNSWindow.Testing
I've written this while trying to make Ryujinx workable on macOS after fixing JIT memory access issues on M1.
Unfortunately Ryujinx requires Vulkan extensions that are not implemented by MoltenVk. So logic is tested by running Ryujinx up to the moment where it checks extensions and throws error on failure to find
VK_EXT_transform_feedbacknot implemented by MoltenVk. This means that initialisation logic inVulkanHelperitself works fine and devices enumeration, extensions enumeration, etc in Ryujinx have no issues.