MacOS support progress/discussion

[johanhenriksson]

So I managed to get a bit further on MacOS support tonight.

• Modified sample 01 to use GLFW for cross-platform window management
• Successfully created a VkSurfaceKHR handle from the GLFW window

To get it working I had to change the default library name from libMoltenVK.dylib to the standard libvulkan.1.dylib. I havent looked into it, but i seem to recall that being correct for newer versions of MVK.

I'm currently stuck at a crash in vk.GetPhysicalDeviceSurfaceSupportKHR, with the output

libc++abi: terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument
SIGABRT: abort

I'm not sure what's causing it, but I'm a little bit suspicious towards the use of dlsym for loading function pointers. As far as I can tell the recommended way is to use vkGetInstanceProcAdd and vkGetDeviceProcAddr, and other platform-specific methods are not supported except as a way to locate those two methods.

[bbredesen]

Do you have a public fork of the samples w/ your changes? I just generated (locally) on mac against 1.2.177. Sample 0 runs successfully for me, but I would like to duplicate the error what you are seeing.

[johanhenriksson]

@bbredesen I pushed a draft PR in the samples repo. Haven't had a chance to keep working on it.

Sample 00 works fine for me too without any changes (besides removing the error strings), the problems occur in sample 01. Would be cool if you can test the GLFW version on windows too, at least some of that code could be useful for cross platform support :)

[bbredesen]

I ran into a ton of issues trying to use GLFW too. GLFW is taking the instance parameter as an interface{} and then using reflection to determine if the handle is a pointer, so I'm wondering if GLFW is doing something weird with Vulkan handles. Dispatchable handles are pointers to a function dispatch table in Vulkan, but intended to be opaque to the programmer, so I don't know why GLFW wants the handle to be a pointer type.

I didn't want to dig too deeply into GLFW so I've adapted the "shared" win32 code to also work with Cocoa, calling out to Objective-C. The good news is that go-vk seems to work just fine on Mac:

I ended up refactoring the whole shared window message model, with impact on how the individual samples setup and start the window. I'm going to push a new branch to [go-vk-samples] shortly, with the caveat that only the basic triangle sample will compile at the moment, so I haven't done much testing yet.

Solving GLFW+go-vk may end up being a requirement though...it is a well-known and commonly used library, and probably a lot of people's first choice to quickly open a opengl or vulkan window on their platform.

[bbredesen]

And also note that I generated a local copy of vk-go against 1.2.203 (last 1.2 revision of vk.xml), with -platform="win32,macos,metal". I'll also push a branch of go-vk for 1.2.

Branch: https://github.com/bbredesen/go-vk/tree/1.2.203-darwin

[johanhenriksson]

Really cool, nice work!

And yeah, this is pretty much the exact use case for GLFW and avoiding it will involve basically re-implementing it, so its probably worth the effort. If it turns out to be too annoying, another idea is to try using SDL2 for cross platform windowing first.

Anyway, CreateWindowSurface seems to be the only (Go) GLFW function that deals with VkInstance handles, so I don't think there can be too much weird things going on in the background. Im guessing the code

(C.VkInstance)(unsafe.Pointer(reflect.ValueOf(instance).Pointer()))

is just a trick to allow any Go object to be cast to a VkInstance, and in order for that to work, we have to pass a pointer to the function. Also, since I managed to get it to create a surface successfully this way, I don't think theres anything sketchy going on here.

[bbredesen]

The rest of the samples have been updated on the shared-framework-update branch and now run on (my) mac.