| Summary: | Support Vulkan Portability rather than MoltenVK specifically | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Dzmitry Malyshau <kvarkus> |
| Component: | render | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | minor | ||
| Priority: | P2 | CC: | icculus, kvarkus |
| Version: | HG 2.1 | Keywords: | target-2.0.10 |
| Hardware: | x86_64 | ||
| OS: | Mac OS X (All) | ||
| Attachments: |
Support gfx-portability natively
Only look for libvulkan.dylib for Vulkan Portability library |
||
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.
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. (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. > 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 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. 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. 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)? 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? 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 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. |
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