Support for MoltenVK

[billhollings]

We at Brenwill, developers of MoltenVK, have received user interest in GLFW supporting Vulkan on macOS (and iOS) by linking to MoltenVK.

If there is GLFW community interest in this, we'd be happy to provide whatever support and advice we can to anyone in the GLFW development community who wishes to update GLFW to support Vulkan on macOS via MoltenVK.

...Bill

[elmindreda]

I'd love to add support for both MoltenVK and MoltenGL, if possible.

[soso7885]

Hope this thing happen! plz...

[elmindreda]

Looking at your license, these sections seem to indicate that GLFW cannot include explicit support for MoltenVK.

You may not distribute an Application containing or using any part of the Software to any third party, without first paying the applicable License Fees for all Developers who contributed to the Application.

You may not distribute a Derivative Work created using a licensed version of any part of the
Software to any third party.

You may not create a Derivative Work, or incorporate any part of the Software into a framework, library, tool, application, or other software used by Developers, unless each Developer using such a Derivative Work or other item holds a valid License to the Software, and adheres to the terms of this license, or unless you have obtained written permission from Us to do so, through a separate written agreement with Us.

You may not use any part of the Software to develop, or cause to be developed, any application, tool, framework, library, or other software that can be used as an alternative to any part of the Software by a third party.

You may not distribute any part of the Software or Documentation outside the use of the
Developer to whom this License is assigned.

[billhollings]

Yes, MoltenVK (and MoltenGL) are distributed under a commercial license, and the sections you refer to would apply if GLFW intended to embed those products in its own distribution in licensed form.

However, that is not necessary. The GLFW community can add support in the sense of using the MoltenVK (or MoltenGL) API if those libraries have been linked (or maybe selected via a build macro setting). It would then be up to the end app developers (i.e.- developers using GLFW) to download MoltenVK (or MoltenGL) and link it if they wanted to use the library. It would also be up to the end app developer to purchase the appropriate license before moving their app to production.

In effect, Molten (either product) would be an optional library that is used if available.

Another option would be for GLFW to include Molten in unlicensed form. That might allow GLFW to better coordinate versioning. It would then be up to an app developer who chose to use the Molten component to purchase the license when they want to go to production.

Molten (both products) can be downloaded and used for development, both by GLFW developers and app developers without having to purchase a license. The Molten licenses only need to be purchased by the app developer when the end app is released for distribution.

Does that clarify the licensing situation? I'm happy to answer any further questions.

[fcvarela]

@billhollings Does Brenwill have a sample implementation of this? It should be relatively easy to plug into these and call MoltenVK from within:

• _glfwPlatformGetRequiredInstanceExtensions
• _glfwPlatformGetPhysicalDevicePresentationSupport
• _glfwPlatformCreateWindowSurface

But some guidance would be greatly appreciated.

[billhollings]

MoltenVK includes several demo apps that help illustrate how to create a Vulkan surface in iOS or macOS, and the README_MoltenVK_UserGuide.md document within the Molten distribution is a useful source of information for installing and integrating MoltenVK into an iOS and macOS development environment.

If you have specific questions as you get into it, please post them to the MoltenVK support forum.

...Bill

[elmindreda]

The GLFW community can add support in the sense of using the MoltenVK (or MoltenGL) API if those libraries have been linked (or maybe selected via a build macro setting). It would then be up to the end app developers (i.e.- developers using GLFW) to download MoltenVK (or MoltenGL) and link it if they wanted to use the library. It would also be up to the end app developer to purchase the appropriate license before moving their app to production.

In effect, Molten (either product) would be an optional library that is used if available.

@billhollings This is the solution I would prefer, with detection at run-time for maximum ease of use.

To clarify, if I add support for the MoltenVK WSI the same way as for the Khronos WSI, i.e. copy the necessary parts of the interface and search for the MoltenVK framework on demand (yes, that code would need to be updated to work with frameworks), this would not require a license from you either of us or any third-party using, modifying or distributing GLFW?

[billhollings]

@elmindreda

Yes...you are correct. By modifying GLFW to enable access to MoltenVK, you (or anyone else distributing GLFW so modified) would NOT require a MoltenVK license.

The MoltenVK licenses would be purchased by a developer who wanted to actually link MoltenVK to GLFW in a production app or game. Once they wanted to move their app to production (and remove the MoltenVK watermark), they would purchase a MoltenVK license for each developer who worked on their app or game (ie- who ran a build that linked the app or game with MoltenVK).

[elmindreda]

@billhollings Perfect. Thank you. I'll start right away.

[billhollings]

@elmindreda

Great!

If there is anything we can help with, or if you have any questions, please don't hesitate to make use of the MoltenVK forum.

[elmindreda]

[elmindreda]

GLFW header version: 3.3.0
GLFW library version: 3.3.0
GLFW library version string: "3.3.0 Cocoa NSGL chdir menubar retina"
OpenGL context version string: "2.1 NVIDIA-10.12.65 355.10.05.05b16"
OpenGL context version parsed by GLFW: 2.1.0
OpenGL context renderer string: "NVIDIA GeForce GT 650M OpenGL Engine"
OpenGL context vendor string: "NVIDIA Corporation"
OpenGL context shading language version: "1.20"
OpenGL framebuffer:
 red: 8 green: 8 blue: 8 alpha: 8 depth: 24 stencil: 8
 samples: 0 sample buffers: 0
 accum red: 0 accum green: 0 accum blue: 0 accum alpha: 0 aux buffers: 0
Vulkan loader: available
Vulkan required instance extensions: VK_KHR_surface VK_MVK_macos_surface
Vulkan discrete GPU device: "NVIDIA GeForce GT 650M"
Vulkan integrated GPU device: "Intel HD Graphics 4000"

[elmindreda]

Sorry about the delay; I've had much less time these past few weeks than I'd hoped. MoltenVK works beautifully and was easy to add support for.

[billhollings]

@elmindreda

Nice work! No need to apologize for the delay...that was actually a rather fast turnaround! I'm glad the effort was fairly straightforward.

The Triangle demo looks wonderful. Are there any other demos within the GLFW library that make use of Vulkan for testing with MoltenVK?

If it's not too corporate, we would like to arrange a press release to announce that GLFW now supports Vulkan on macOS and iOS through MoltenVK. Would you mind if we include your rather positive quote above in that press release? No trouble either way...I completely understand if you'd rather not be seen to publicly endorse products outside GLFW.

Thanks...

...Bill

[fcvarela]

@elmindreda This is amazing, has it been pushed to any branch? I'd like to give it a try! Thanks.

[dmitshur]

announce that GLFW now supports Vulkan on macOS and iOS through MoltenVK.

@billhollings Emphasis mine, but what makes you say that GLFW supports iOS? As far as I know, it does not.

[billhollings]

@shurcooL

Thanks for pointing that out.

My bad. I'm just used to automatically mentioning both OS's when discussing MoltenVK. :^)

...Bill

[elmindreda]

@billhollings Basic (and somewhat kludgy) support for MoltenVK has been merged with e94d166 and will be included in 3.3. It can of course be improved before release.

Are there any other demos within the GLFW library that make use of Vulkan for testing with MoltenVK?

Not currently. I'm hoping to have time to write some, but GLFW itself takes priority.

If it's not too corporate, we would like to arrange a press release to announce that GLFW now supports Vulkan on macOS and iOS through MoltenVK.

That's fine [now that I've merged it]. Go ahead.

Would you mind if we include your rather positive quote above in that press release? No trouble either way...I completely understand if you'd rather not be seen to publicly endorse products outside GLFW.

No, please don't quote me. The above issue aside, I haven't used enough of MoltenVK to give a verdict on the product as a whole yet.

@fcvarela You can find it in master now. Note that you need to help CMake find the MoltenVK framework, as it's not installed anywhere. If you're on the command-line, CMAKE_FRAMEWORK_PATH is handy.

[elmindreda]

There is also an occasional segfault remaining in void mvkRemoveFirstOccurance<std::__1::unordered_set<MVKPipeline*, std::__1::hash<MVKPipeline*>, std::__1::equal_to<MVKPipeline*>, std::__1::allocator<MVKPipeline*> >, MVKPipeline*>(std::__1::unordered_set<MVKPipeline*, std::__1::hash<MVKPipeline*>, std::__1::equal_to<MVKPipeline*>, std::__1::allocator<MVKPipeline*> >&, MVKPipeline*) when calling vkDestroyPipeline, which I assume is my fault as it doesn't appear to occur for the bundled demos.

[kusma]

Now that MolkenVK is open source, what would be needed to use GLFW with it through brew (glfwVulkanSupported() returns falsem and vkCreateInstance() fails)? Is that up to the brew settings?

[HindrikStegenga]

Hello, since the release of the MacOS SDK yesterday for Vulkan, I'm trying to get GLFW to work with it.
However, glfwCreateWindowSurface throws a BAD_ACCESS at address 0x70 when linking to the loader library. When linking directly to the moltenVK library, it seems to work correctly. (Although without layers/extensions). Can you guys look at why it does this? Other functions using the loader library work as expected, as I can create a vkInstance and everything.

@kusma You should use brew install glfw3 --HEAD to get the latest GLFW, which you can use for MoltenVK.

[elmindreda]

@Hindrik1997 Yup, sorry about that. Looking into it now.

[kusma]

@Hindrik1997: Thanks for the tip. Sadly this didn't help me much, I still get the same problem (glfwVulkanSupported() returns non-true, vkCreateInstance() fails) with that version as well. glfwGetVersionString returns "3.3.0 Cocoa NSGL dynamic", and pkg-config --cflags glfw3 prints -I/usr/local/Cellar/glfw/HEAD-0d45347/include, which seems appropriate.

[kusma]

vkCreateInstance() fails with VK_ERROR_LAYER_NOT_PRESENT due to missing debug-layers. If I drop those, it fails with VK_ERROR_INCOMPATIBLE_DRIVER. Sounds like something isn't quite right with the MoltenVK usage. I'm trying to use it from the LunarG Vulkan SDK, by the way. I'm just using pkg-config for build-flags, and patching up rpath with install_name_tool -change @rpath/libvulkan.1.dylib $VULKAN_SDK/macOS/lib/libvulkan.1.dylib...

[kusma]

Yeah, even $VULKAN_SDK/macOS/bin/vulkaninfo fails to load. I guess there's a problem with the vulkan loader on my system. The examples that link directly to the MoltenVK SDK seems to work. So, seems not like a GLFW-issue. Sorry for the noise.

[HindrikStegenga]

@kusma
You MUST use brew install glfw3 --HEAD, because the default brew (3.2.1) release does NOT support MoltenVK.

What I did was to setup a few environment variables for the SDK directoriesto my .bash_profile. Basically this:
PATH="vulkansdk/macOS/bin:$PATH" DYLD_LIBRARY_PATH="vulkansdk/macOS/lib" VK_LAYER_PATH="vulkansdk/macOS/etc/explicit_layers.d" VK_ICD_FILENAMES="vulkansdk/macOS/etc/icd.d/MoltenVK_icd.json" VULKAN_SDK="vulkansdk/macOS"

After that I included $VULKAN_SDK/lib and $VULKAN_SDK/include in my CMakeLists. After which I linked my target to the vulkan loader lib. Since GLFW was installed to /usr/local/bin, I added these dirs to my CMakeLists too. Don' t forget to add glfw to the linked library list. This should work, good luck!

If you have added this correctly, vulkaninfo should just work from the terminal too.

However, as I mentioned earlier, GLFW crashes when retrieving the VkSurface when using the loader lib. Directly linking to the MoltenVK library without the loader does seem to work though, but yeah, no layers or extensions then.

[kusma]

@Hindrik1997: Sure, and I did :)

OK, setting up VK_LAYER_PATH and VK_ICD_FILENAMES as you suggested made vulkaninfo work just fine.

Sadly, it didn't help with my glfwVulkanSupported()-problem, it still reports false. Also glfwGetPhysicalDevicePresentationSupport() returns false for the only queue, and if I ignore that and pick the queue anyway, glfwCreateWindowSurface() fails. So it seems there's something else up with my setup here. It seems like vulkan-support might be compiled out of my GLFW-build. Perhaps I need to setup some environment variables before installing the brew-package (assuming brew builds from source)?

[HindrikStegenga]

@kusma Yes, those variables are required for the Vulkan loader to figure out where it can find the driver's implementation. (Hence the name, Installable Client Driver) Same goes for the layers and extensions.
Try uninstalling and installing glfw again, who knows it helps. In my case glfwVulkanSupported returns 1, (GLFW_TRUE). To what library do you link it? The loader or directly to MoltenVK.dylib ? Do you also use CMake? Also, does it throw an error on glfwCreateWindowSurface() for you too?

[kusma]

Reinstalling GLFW from brew (HEAD) after setting these environment doesn't seem to help for me. I seem to still get a GLFW without any vulkan support.

I link to the loader, not MoltenVK.dylib. I don't use CMake, I use meson. But I think the result should be the same.

[HindrikStegenga]

@kusma
You would think so, yes. I have never worked with meson, so I can't help in that regard. Can you create a VkInstance without GLFW? (Just create one without any layers or extensions, it should return VK_SUCCESS) If you can't, your problem has nothing to do with GLFW, but rather your MoltenVK setup. Can you show me how you set up your directories and meson build file? (Pastebin link)
Because if glfwCreateWindowSurface() crashes in your case too, we know it's either the loader or glfw going wrong here.

[kusma]

@Hindrik1997: I can create vulkan-instances just fine, but glfwVulkanSupported() and glfwGetPhysicalDevicePresentationSupport() both says no. If I ignore both, glfwCreateWindowsSurface() fails. This is both before and after ab3bfb4.

[kusma]

Here's a stripped down version of my project.

configure:
meson build -Dvulkan-sdk=$VULKAN_SDK
build:
ninja -C build/
fixup rpath:
install_name_tool -change @rpath/libvulkan.1.dylib $VULKAN_SDK/lib/libvulkan.1.dylib build/vulkan-test

[HindrikStegenga]

@kusma
After commit ab3bfb4, does glfwCreateWindowSurface() fail with a return value or does it throw a BAD_ACCESS?

The only thing that is definately a problem is the following line in your meson.build:
glfw_dep = dependency('glfw3', version : '>=3.2')
You need to set this to 3.3, since 3.2 does not support moltenVK.

Check which version is linked by printing out the GLFW_VERSION_* macro's.

What does the rpath stuff do? And do you link statically or dynamically with GLFW?

[kusma]

@Hindrik1997: It always failed with a return value for me.

And yes, I'm aware that I need GLFW 3.3, but in my case that's what I've got installed. Changing it in the meson.build-file won't change anything. Also, as I said above, glfwGetVersionString() returns "3.3.0 Cocoa NSGL dynamic".

The rpath-stuff isn't needed, and.... uh. Yeah, I just found out what the problem was; I had a typo in my DYLD_LIBRARY_PATH-variable. And my rpath-stuff was papering over the symptoms of this. Sorry for the noise, and thanks a lot for the help!

[kusma]

OK, things works now. I get a validation issue, though:

ERROR: [ParameterValidation] Code 201502731 : vkCreateMacOSSurfaceMVK: parameter pCreateInfo->sType must be VK_STRUCTURE_TYPE_MACOS_SURFACE_CREATE_INFO_MVK. The spec valid usage text states 'sType must be VK_STRUCTURE_TYPE_MACOS_SURFACE_CREATE_INFO_MVK' (https://www.khronos.org/registry/vulkan/specs/1.0-extensions/html/vkspec.html#VUID-VkMacOSSurfaceCreateInfoMVK-sType-sType)

Also, at the end of my application, I do a vkQueueWaitIdle() which never terminates. But I assume this is a MoltenVK quirk, not a GLFW one.

[HindrikStegenga]

@kusma

The surface creation structure type should be something related to GLFW I think. It probably forgets to set it to the right type. Either way, you should use vkDeviceWaitIdle() instead. Make sure no command buffers are in flight anymore.

[elmindreda]

ERROR: [ParameterValidation] Code 201502731 : vkCreateMacOSSurfaceMVK: parameter pCreateInfo->sType must be VK_STRUCTURE_TYPE_MACOS_SURFACE_CREATE_INFO_MVK. The spec valid usage text states 'sType must be VK_STRUCTURE_TYPE_MACOS_SURFACE_CREATE_INFO_MVK' (https://www.khronos.org/registry/vulkan/specs/1.0-extensions/html/vkspec.html#VUID-VkMacOSSurfaceCreateInfoMVK-sType-sType)

Found it. The value of VK_STRUCTURE_TYPE_MACOS_SURFACE_CREATE_INFO_MVK changed between MoltenVK 0.15 and 0.16 but I didn't notice at the time. This has been fixed with 94ffc12.

[kusma]

@elmindreda: Nice. I can confirm that this is no longer a problem :)