Remove GLFW dependency

[jclc]

The long-term goal should be to remove the hard dependency on GLFW so the bindings can be used with any windowing library.

[xlab]

Good point, any good alternatives to GLFW are welcome. I'd like to see and example of SDL+vulkan

[jclc]

https://github.com/veandco/go-sdl2/ is only missing 6 Vulkan functions, making a wrapper around them shouldn't be too difficult. However, is it possible to transfer C types between different packages? Or should uintptrs be used instead? SDL_Vulkan_CreateSurface takes a VkInstance and a VkSurface as parameters.

Also, it seems that you can't set the InstanceProcAddr on vulkan-go. How about adding support for letting SDL2 find the symbols?

[xlab]

@jclc uintptrs should be used, please check out https://github.com/vulkan-go/vulkan/blob/master/vulkan_linux.go these functions are hand-written. So we need to have vulkan_linux.go and vulkan_linux_sdl2.go, the latter with proper calls of the corresponding SDL2 functions.

[jclc]

I'm really not a fan of having to individually support every possible windowing library in the Vulkan bindings. It shouldn't be the Vulkan bindings' responsibility to implement wrappers around these functions. Especially GetRequiredInstanceExtensions, since those functions in both GLFW and SDL2 don't require Vulkan at all, only their respective window handle pointers.

I finished SDL2 Vulkan functions (https://github.com/veandco/go-sdl2/issues/353) but they still use the C types. If it works out, I'll change the functions that take VkSurface and VkInstance to accept uintptrs. What is the state of GLFW's Vulkan support however? I see the examples still use your fork. Is the support not in upstream GLFW yet?

Also, Go 1.11 and modules are out 🎉! Should we start using git tags for versioning?

[jclc]

How about this:

• vk.Init should take a uintptr to the Vulkan GetProcAddr function in order to load symbols. This lets us init without starting up GLFW.
• Remove CreateSurface functions. Can instead add it back in vulkan-go/glfw. This function should then accept a uintptr to VkInstance and return a uinptr containing a VkSurface. I've already made this function for SDL2 but haven't pushed it upstream yet.

[jclc]

I've been working on a big refactor over the weekend. Had to touch up vulkan-go/vulkan, asche, demos and vulkan-go/glfw to root out the dependency on GLFW functions. The calls to glfwGetInstanceProcAddress have been replaced by having the user call vk.SetGetInstanceProcAddr(unsafe.Pointer) or vk.SetDefaultGetInstanceProcAddr() before vk.Init(). The former accepts a pointer returned by a similar function in GLFW and SDL2. The latter does what "compute" used to do on Linux - load the Vulkan library manually - except it doesn't require any build flags anymore. It could be extended to work on Windows and Mac later. I decided against setting the pointer in vk.Init since I think it's good to let users think about which one to use (I would let the windowing library deal with it if using one).

I'll have a bunch of pull requests coming up to all the aforementioned repos, please take a look at them all. Now would also be a good time to add a version tag since this breaks everything.

[xlab]

It shouldn't be the Vulkan bindings' responsibility to implement wrappers around these functions.

Unfortunately this is how Vulkan API was organised, it has functions for each platform it supports, e.g. XCB, Android or whatever. Anyway, thanks for your work on decoupling this stuff.

[xlab]

Amazing work @jclc, thank you very much. I just reviewed the examples, it looks well and works!!. Btw, SDL2 doesn't work on my macOS with MoltenVK, all functions return NULL:

       // orPanic(sdl.VulkanLoadLibrary(""))
       // defer sdl.VulkanUnloadLibrary()

       log.Println("Vulkan loading:", sdl.VulkanLoadLibrary(""))
       log.Println("Error?", sdl.GetError())
       log.Println("Vulkan loaded:", sdl.VulkanGetVkGetInstanceProcAddr())

Prints NULL, NULL, NULL. Will debug that, wtf :(

It shouldn't be the Vulkan bindings' responsibility to implement wrappers around these functions.

You were 100% correct on that. The only exceptions are Android / iOS platforms that don't have any sophisticated loader yet.

[jclc]

I'm sorry, I don't have a Mac so I can't debug this myself. Which version of SDL2 are you using? Vulkan functions were added in 2.0.6, but for backwards compatibility, the Go bindings implement stubs which return NULL for functions that aren't implemented in that particular version of SDL2. Also, does the GLFW example work?

[jclc]

From the SDL2 wiki (https://wiki.libsdl.org/SDL_Vulkan_LoadLibrary):

On Apple devices, if path is NULL, SDL will attempt to find the vkGetInstanceProcAddr address within all the mach-o images of the current process. This is because it is fairly common for Vulkan applications to link with libvulkan (and historically MoltenVK was provided as a static library). If it is not found then, on macOS, SDL will attempt to load vulkan.framework/vulkan, libvulkan.1.dylib, MoltenVK.framework/MoltenVK, and libMoltenVK.dylib in that order. On iOS SDL will attempt to load libMoltenVK.dylib. Applications using a dynamic framework or .dylib must ensure it is included in its application bundle.

It seems like the MoltenVK library must be bundled with the application or be installed on the system.

[xlab]

@jclc yes GLFW works well, I tested everything using GLFW.

As for SDL2, I have frameworks in /Library/MoltenVK.framework so it must be in the search path too.. I think this is purely macOS specific, I'll find the issue and report back.

[xlab]

@jclc turns out that some kind of build cache is involved, as any change to C files in github.com/veandco/go-sdl2/sdl results is a successful re-compilation and the app works.

I tried to use go clean but the most successful fix was to remove $GOPATH/pkg lol :)