Help needed with KHR extensions

Vulkan
1

Another newbie question:
I am in a Win10/MSVS 2015 environment and using freeglut to interface with the windowing system.

I have created a Vulkan instance, now want to create a surface. So I enabled KHR extensions as below in instance creation:

	std::vector<const char*> enabledExtensions;
	enabledExtensions.push_back("VK_KHR_surface");
	enabledExtensions.push_back("VK_KHR_win32_surface");

	createInfo.enabledExtensionCount = enabledExtensions.size();
	createInfo.ppEnabledExtensionNames = &enabledExtensions[0];

Next, to make the surface I start with:

	VkWin32SurfaceCreateInfoKHR createInfo;
	createInfo.sType = VK_STRUCTURE_TYPE_WIN32_SURFACE_CREATE_INFO_KHR;
	createInfo.hwnd = windowHandle;
	createInfo.hinstance = processHandle;

And there’s where I run into trouble. There’s a red line under VkWin32SurfaceCreateInfoKHR. I guess this has to do with including some header file but not sure what.

Follow-up question after, hopefully, the above is resolved. To create the surface I have

VkResult result = vkCreateWin32SurfaceKHR(instance, &createInfo, NULL, &surface);

Again vkCreateWin32SurfaceKHR is underlined so same problem there I guess. But is this the correct statement in the first place? Reason I ask is that I have seen code in another tutorial which uses a statement containing PFN_vkCreateWin32SurfaceKHR - I don’t understand the PFN_ deal at all.

Btw, I use the following to find the window and process handles:

	processHandle = GetModuleHandle(nullptr);
	windowHandle = FindWindow(NULL, LPCTSTR("Window title"));

Correct I hope.

Another thing, I know that GLFW is more Vulkan-friendly then freeglut but I’ve used freeglut a lot with OpenGL so want to keep with it.

2

The platform-specific surface creation functions need be enabled using defines. For Windows you need to define VK_USE_PLATFORM_WIN32_KHR in your project’s windows build configuration somewhere:

#ifdef VK_USE_PLATFORM_WIN32_KHR
#define VK_KHR_win32_surface 1
#include <windows.h>

#define VK_KHR_WIN32_SURFACE_SPEC_VERSION 5
#define VK_KHR_WIN32_SURFACE_EXTENSION_NAME "VK_KHR_win32_surface"

typedef VkFlags VkWin32SurfaceCreateFlagsKHR;

typedef struct VkWin32SurfaceCreateInfoKHR {
...

If code uses PFN_vkCreateWin32SurfaceKHR then it probably does manual function pointer loading, which is not required in most cases unless you use extensions that are not part of the core or wsi.

3

AFAIK FreeGLUT does not support Vulkan. It would probably try to create OpenGL context on top of the created window, which would put a wrench in things. Besides, you have to use a hack to get the HWnd out of it. And besides doing it in non-multi-platform way. Don’t be afraid to learn new things; is fun. GLFW is quite basic. You will learn it in no time. Or you could steal my stuff to get started: https://github.com/krOoze/Hello_Triangle/blob/master/glfwPlatform.h

Be specific. Gimme real compiler errors, not “squiggles”. Likely the missing VK_USE_PLATFORM_WIN32_KHR though.

You don’t need to worry about PFN_. As long as you are using the official Vulkan Loader, the core and the WSI commands will be loaded automagically.

For completness: PFN_ is a function pointer type of the given Vulkan command. It is useful when loading commands yourself. You would get a void*, so you need to convert it to appropriate command, e.g.

PFN_vkCreateDebugReportCallbackEXT pvkCreateDebugReportCallbackEXT = reinterpret_cast<PFN_vkCreateDebugReportCallbackEXT>(
    vkGetInstanceProcAddr( instance, "vkCreateDebugReportCallbackEXT" )
);
4

Thanks, Sascha Willems and krOoze.

krOoze: “It would probably try to create OpenGL context on top of the created window, which would put a wrench in things.” Absolutely right, just checked: glutCreateWindow() creates an OpenGL context.

So that settles my problems with freeglut because I am not going to try to use it with Vulkan anymore. GLFW it is, which I have used a bit before but just wanted to see if I could wrangle some of the Vulkan tutorial code out there from GLFW to freeglut figuring I would learn Vulkan in the process too having to break the code down.

Ah, well. Thanks again.