We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4570 - Support Vulkan Portability rather than MoltenVK specifically
Summary: Support Vulkan Portability rather than MoltenVK specifically
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: render (show other bugs)
Version: HG 2.1
Hardware: x86_64 Mac OS X (All)
: P2 minor
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords: target-2.0.10
Depends on:
Blocks:
 
Reported: 2019-03-28 18:06 UTC by Dzmitry Malyshau
Modified: 2019-06-12 01:15 UTC (History)
2 users (show)

See Also:

Attachments
Support gfx-portability natively (7.53 KB, patch)
2019-03-28 18:09 UTC, Dzmitry Malyshau 		Details | Diff
Only look for libvulkan.dylib for Vulkan Portability library (7.48 KB, patch)
2019-06-11 20:01 UTC, Dzmitry Malyshau 		Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Dzmitry Malyshau 2019-03-28 18:06:50 UTC 
Current code, search paths, and error messages are written to only consider MoltenVK on macOS as a Vulkan Portability implementation. It's not the only implementation available to the users. gfx-portability [1] has been shown to run a number of titles well, including Dota2, Dolphin Emulator, and vkQuake3, often out-performing MoltenVK in frame rate and stability (see Dolphin benchmark [2]).

There is no reason for SDL to be that specific, it's not using any MVK-specific functions other than the WSI initialization ("VK_MVK_macos_surface"). gfx-portability exposes this extension as well, and a more generic WSI extension is in process. It would be good if SDL was written in a more generic way that expect a Vulkan Portability library as opposed to MoltenVK specifically.

[1] https://github.com/gfx-rs/portability
[2] https://gfx-rs.github.io/2019/03/22/dolphin-macos-performance.html
Comment 1 Dzmitry Malyshau 2019-03-28 18:09:29 UTC 
Created attachment 3716 [details]
Support gfx-portability natively

No hard feelings about "libMoltenVK.dylib" and "libportability.dylib". It would be nice to just expect something like "libVulkan.dylib", but that would break some of the compatibility with existing apps.
Comment 2 Dzmitry Malyshau 2019-03-28 18:12:34 UTC 
Also note: I haven't built the iOS version of SDL to confirm that the changes compile. I assume there is CI in place to guard against that. Let me know if you'd prefer this tested on my side, and I'll think something out.
Comment 3 Ryan C. Gordon 2019-03-29 03:14:22 UTC 
(In reply to Dzmitry Malyshau from comment #1)
> No hard feelings about "libMoltenVK.dylib" and "libportability.dylib".

I really would have rather this be called something like "libvkportability," but I guess that's already been decided elsewhere.

I haven't looked at the details of the patch, but I'm fine with the idea of this. I'll add this to my 2.0.10 TODO list.

--ryan.
Comment 4 Dzmitry Malyshau 2019-03-29 16:18:50 UTC 
> I really would have rather this be called something like "libvkportability,"
> but I guess that's already been decided elsewhere.

Not it wasn't decided. To clarify `libportability` is not a name the working group suggests for apps to link to, it's just the target name for gfx-portability library. Just like there isn't a standard name for a random Vulkan driver, there isn't one for the Vulkan Portability. There is a precedent though which would be useful to follow for consistency with the ecosystem: Vulkan CTS uses "libvulkan.dylib" on macOS [1].

[1] https://github.com/KhronosGroup/VK-GL-CTS/blob/fd68124a565ef6f0a6e3fee6d9d29493ed875be9/framework/platform/osx/tcuOSXVulkanPlatform.cpp#L79
Comment 5 Ryan C. Gordon 2019-05-18 18:48:53 UTC 
Tagging a bunch of bugs with "target-2.0.10" so we have a clear list of things to address before a 2.0.10 release.

Please note that "addressing" one of these bugs might mean deciding to defer on it until after 2.0.10, or resolving it as WONTFIX, etc. This is just here to tell us we should look at it carefully, and soon.

If you have new information or feedback on this issue, this is a good time to add it to the conversation, as we're likely to be paying attention to this specific report in the next few days/weeks.

Thanks!

--ryan.
Comment 6 Sam Lantinga 2019-05-22 03:09:41 UTC 
According to the docs:
Dynamic linking
Typically, you'd need to create a symbolic link with a name that a target application expects, e.g. libvulkan.dylib -> libportability.dylib.

Maybe we don't use libportability.dylib? That is so generic, we might accidentally load something else on the end user's system.
Comment 7 Dzmitry Malyshau 2019-05-22 15:46:30 UTC 
Sam,

I understand the point of "libportability" being too generic. We'll consider renaming it to something like "libgfxportability". Meanwhile, perhaps SDL2 could just look for "libvulkan" like Vulkan CTS does instead of trying concrete libraries (libMoltenVK/libportability)?
Comment 8 Sam Lantinga 2019-06-08 21:47:17 UTC 
Sure, can you update the patch with this change? It looks like the Mac OS X code already tries to load libvulkan.1.dylib, is that sufficient?
Comment 9 Dzmitry Malyshau 2019-06-11 20:01:25 UTC 
Created attachment 3819 [details]
Only look for libvulkan.dylib for Vulkan Portability library

Updated to only look for "libvulkan.dylib". This appears to be in line with LunarG recommendation here:
https://github.com/KhronosGroup/Vulkan-Portability-PoC/issues/54#issuecomment-499994356
Comment 10 Sam Lantinga 2019-06-12 01:15:05 UTC 
Patch added, thanks!
https://hg.libsdl.org/SDL/rev/4a089aa4ff81

I tweaked it to also look for MoltenVK, since there are shipping games that use it, but it prefers libvulkan.dylib if that is available.