Note that glfwCreateWindowSurface calls vkCreateWin32SurfaceKHR so if you are gettting an error from GLFW but not from vkCreateWin32SurfaceKHR then it’s likely that GLFW has errored at an earlier point in glfwCreateWindowSurface as there are several checks. You can either step debug through the program to check or use glfwSetErrorCallback and print out the error.
Well, I just tried the modified version: the one in which the call to glfwCreateWindowSurface is commented out and replaced by the code mentioned in my second reply (actually it could be my first message to this forum) and added the proper headings mentioned above, the code runs fine without messages or anything in both mingw64 and VS 2017 Community…
While keeping the glfwCreateWindowSurface gives a lot of complaining from VS and segmentation fault when run…
Well the segmentation fault happens only in mingw64 but not in VS in debug mode…
The tutorial is now working on my machine - I hadn’t named the shader files correctly so it was loading glsl instead of the spir-v output from glslx.exe as per the tutorial page on shader modules. This worked without validation layers but not with them.
It sounds like you may be having an issue with mingw64 and GLFW now, I cannot be sure from your reply. If you can use Visual Studio then I would highly recommend it over mingw.
I see what you mean glfwCreateWindowSurface returns 0 and works fine for VS in the case of squareVulkanized program while in mingw64 under MSYS2 it returns -7 and a NULL pointer in surface and that is why it crashes; even though the instance is created with the correct enabled 2 extensions and the call to vkCreateInstance returns 0. I wonder what could that be?since glfwCreateWindowSurface works fine for triangle-vulkan.c in mingw64.
An error or -7 is VK_ERROR_EXTENSION_NOT_PRESENT, which is set in potentially multiple places. You would need to use glfwGetError to get the error string pointer which you can then print, or debug the call to glfwCreateWindowSurface.
Additional note: it’s possible that the tutorial is adding extension requirements which are not available via mingw64. In debug VK_LAYER_KHRONOS_validation is added and VK_KHR_swapchain is requested in both release and debug.
Well, I checked the Extension names and they are fine the win32 extension is there the second one.
Anyway, I was able to get squareVulkanized to work in MSYS2 (mingw64 subshell) and get myself confused. Well it is working with no messages or segmentation fault but I don’t understand. I decided to imitate triangle-vulkan.c and link with glad and include vulkan headers from vulkan as in triangle-vulkan.c.
Still didn’t work, so next thing is duplicate the use of
static GLADapiproc glad_vulkan_callback(const char* name, void* user)
{
return glfwGetInstanceProcAddress((VkInstance) user, name);
}
and replaced the call of glfwCreateWindowSurface by:
glfwCreateWindowSurface(instance, window, NULL, &surface);
gladLoadVulkanUserPtr(physicalDevice, glad_vulkan_callback, instance);
so now glfwCreateWindowSurface returns 0 and surface is not NULL anymore it points to a valid memory address, but still I kept getting segmentation fault from:
vkCreateSwapchainKHR
so I did the exact same thing by replacing its call by:
gladLoadVulkanUserPtr(physicalDevice, glad_vulkan_callback, NULL);
vkCreateSwapchainKHR(logicalDevice, &createInfo, NULL, &swapchain);
that is added the call to glad function before it, and here is our square without complaints or messages…
I really was able to solve the problem of program not running in MSYS2 and running in VS but created a new problem that is why is that? Hope you can help with that…
As per my comments about I would first recommend investigating the error returned by GLFW in the original sample code.
OK I will, but just for the fun of it I did the exact same thing in the hello triangle tutorial, that is linked with glad and placed call to glad before the surface and swapchainkhr as in my previous message. Also I had to comment out all the debug declarations and functions since their needed header declarations are not available anymore in the new header included by glad insteag of glfw; and it worked without doing any low level non-cross platform coding…
I did debug in mingw64 with gdb and first found that the extensions are 3 and not 2 so I recompiled with -DNDEBUG and made sure that there are 2 extensions with win32 surface the second one to make debugging easier.
I made a break point at the call of the function _glfwPlatformCreateWindowSurface which got called and I noticed that the troubles are in these lines:
vkCreateWin32SurfaceKHR = (PFN_vkCreateWin32SurfaceKHR)
vkGetInstanceProcAddr(instance, "vkCreateWin32SurfaceKHR");
if (!vkCreateWin32SurfaceKHR)
{
_glfwInputError(GLFW_API_UNAVAILABLE,
"Win32: Vulkan instance missing VK_KHR_win32_surface extension");
return VK_ERROR_EXTENSION_NOT_PRESENT;
}
It is glfwInputError that get called and causes failure in creating the surface.
According to the terse documentation of vkGetInstanceProcAddr it is loader/platform dependent function. For windows it is the glad loader and the vulkan-1.dll that performs the magic of executing it, hence I can understand why using glad made the code works.
On the other hand in VS, the code works fine without glad, so there must be some way the standard vulkan loader along with vulkan-1.dll make vkGetInstanceProcAddr works. How is that can be made explicitly, obviously VS compiler does it implicitly that is initializing the standard vulkan loader properly.
I forgot to mention in my previous message that when I print vkCreateWin32SurfaceKHR in gdb it has non-zero value and also printing !vkCreateWin32SurfaceKHR then gdb responds with the value false. Nonetheless _glfwInputError inside the IF is executed and surface creation failure is reported. How come the negation of non-zero value evaluates to true unless somehow the runtime system knows it is an invalid function address from its type…Right?
It just occurred to me, may be just because of the wrong reasons the original squareVulkanized works fine in VS, since vkCreateWin32SurfaceKHR is nonzero but invalid extension function address the runtime in VS does not perform type checking and the negation of nonzero is False and hence it skips the IF and really create the win32 surface by calling the correct function directly instead of retrieving its address…
I’m not familiar enough with MinGW to help you here, and would recommend using Visual Studio compiler for Windows if you can.
The if statement if (!vkCreateWin32SurfaceKHR) will not be entered if vkCreateWin32SurfaceKHR is non-zero, so it’s likely you’ve made an error in your debugging.