Allow dynamic linking of molten-vk on MacOS. #103
Conversation
| // Molten-vk doesn't support the full Vulkan feature set, hence the portability subset extension must be enabled. | ||
| #[cfg(all(target_os = "macos", feature = "macos-dynamic-molten-vk"))] | ||
| { | ||
| enabled_ext_names.push(khr::portability_subset::NAME.as_ptr()); | ||
| } | ||
|
|
There was a problem hiding this comment.
Shouldn't this be enabled for target_os = "macos" regardless of macos-dynamic-molten-vk? Same question below for ash::khr::portability_enumeration, etc...
There was a problem hiding this comment.
Examples from ash:
https://github.com/ash-rs/ash/blob/55dc692946f52f0dff326bd13b1722d98f52fd2b/ash-examples/src/lib.rs#L317
https://github.com/ash-rs/ash/blob/59163296473aa6cb72ee0c4a63b25d7bb9823616/ash-examples/src/lib.rs#L233
(I have these in my screen-13 fork and have been meaning to make a PR)
There was a problem hiding this comment.
I'll leave a longer top-level comment with more details, but in short I've tried that, but it errors out at runtime when requesting those extensions, but not linking dynamically. The error states that "Vulkan Error: Extension specified does not exist."
I suspect (not verified though) this is because screen-13 defaults to using ash-molten, which in turn statically links against an outdated version of MoltenVK.
|
@karhu Would you be able to provide/link a bit of docs on how to use this feature (dynamically linking Vulkan, using Vulkan validation layers on MacOS)? If so, I would be happy to test it. |
|
@DGriffin91 Thanks for taking the time to look into this. I'm far from an expert on Vulkan tbh, but I'm happy to provide some context based on my understanding: The current version of screen-13 has different behavior on MacOS, compared to other platforms (Win, Linux, ...?). Vulkan validation layers work by injecting verification logic into your application when the dynamically linked Vulkan symbols are resolved at runtime. This allows enabling/disabling them without recompiling the target binary. The undesirable consequences of this are:
On the other hand, the desirable consequences of this are:
Check the ash-molten page, as they are pretty open about that in their project description. |
|
As for testing instructions:
|
|
Thank you for those instructions - I've never taken the time to try out dynamic linking Vulkan on Mac but I definitely want the debugging layers there. Mac has always been a "best-effort" platform for what I've been doing and I would like this get merged. I'll test on the Mac's I have access to:
|
|
Glad to hear! Btw, I'm curious about your preference as to which linking behavior should be the default, and which opt-in via feature flag. I implemented it the way it is right now in order to not break any existing behavior. Defaulting to "static linking" definitely has the advantage that it is more likely to "just work". On the other hand, defaulting to dynamic linking would make the library more consistent across platforms. |
|
Sorry for the delay, I've just now tried this and it works as described. I would like to swap the feature flag for I'll add some details to the documentation before release, too:
... but probably more wordy. The way I put that does seem super confusing. |
|
@karhu I'll make the above changes, if that's alright with you? |
3 participants
I wanted to use Vulkan validation layers on MacOS. The changes below are what's necessary to dynamically link Vulkan from an installed Vulkan SDK.
I've moved these changes behind a new feature-flag, to keep the static linking behavior as default on MacOS.
Please take a look :)