MoltenVK loader

[rongcuid]

Version

3.3.2 (nightly), 3.3.1

Platform

macOS arm64

JDK

OpenJDK 17

Module

Vulkan

Bug description

LWJGL tries to load MoltenVK directly by default. This does not provide any layer apart from MoltenVK, meaning there is no validation to enable, and more critically no VK_KHR_portability_enumeration extension. The former makes development very difficult, while the latter outright makes it impossible to create a Vulkan Instance. I have to override org.lwjgl.vulkan.libname to the full path o loader dylib to make Vulkan work.

Relevant file: modules/lwjgl/vulkan/src/main/java/org/lwjgl/vulkan/VK.java.

Stacktrace or crash log output

No response

[Spasi]

Hey @rongcuid,

I have to override org.lwjgl.vulkan.libname

Yes, this is by design. LWJGL prefers the bundled MoltenVK build by default.

to the full path o loader dylib to make Vulkan work

When installing the Vulkan SDK, there is an option to install it system-wide. LWJGL is then able to pick it up without a full path (just libvulkan.1.dylib). In any case, this is not an issue with LWJGL.

while the latter outright makes it impossible to create a Vulkan Instance

Not sure what you mean. I just installed the Vulkan SDK, set org.lwjgl.vulkan.libname accordingly, then enabled the KHR_portability_enumeration instance extension and the KHR_portability_subset device extension. I was then able to run the HelloVulkan sample with validation enabled.

[rongcuid]

For first part, I installed the Vulkan SDK with system loader under /usr/local/lib/libvulkan.dylib (which is installed by the SDK installer). However, LWJGL does not detect the loader if I do not specify the full path.

For the second part, if I specify libname directly, all the extension indeed work, as expected. However, when I am not specifying the libname, LWJGL loads MoltenVK directly and does not come with KHR_portability_subset extension. This means that the bundled librar will not run standalone, because without this extension I would get driver error.

[Spasi]

Hey @rongcuid,

It's still not clear to me what problem you're having and what LWJGL could do differently to improve the situation. Afaict:

• option 1: Run with the defaults, no org.lwjgl.vulkan.libname. LWJGL picks up the bundled MoltenVK. You do not have access to validation layers. You do not enable KHR_portability_enumeration or KHR_portability_subset. The program should just work.
• option 2: Run with -Dorg.lwjgl.vulkan.libname=libvulkan.1.dylib and the Vulkan SDK installed. You have to enable both KHR_portability_enumeration and KHR_portability_subset, otherwise instance creation fails. Validation layers are also available if you need them.

If I understood correctly, option 2 works for you (except you need to specify an absolute path to the Vulkan loader). What is the issue exactly with option 1?

[rongcuid]

Option 1 does not actually work. It gives the incompatible driver error, indicating that portability must be enabled.

[Spasi]

Could you please post the full output when running option 1 with -Dorg.lwjgl.util.Debug=true -Dorg.lwjgl.util.DebugLoader=true?

[Spasi]

I've been able to test this on an M2. As before, option 1 works fine without validation enabled. However, like @rongcuid, for option 2 I had to specify the full path to libvulkan.1.dylib. I can't explain this, other than a possible difference in default dlopen behavior between macOS 12 and 13.

Anyway, there's no problem with LWJGL, so closing this.