Update Vulkan loader to support Roadmap 2026 WSI extensions directly

[pdaniell-nv]

The Vulkan loader supports the Vulkan 1.4 core API as Direct Exports, which means the application can link to vulkan-1.lib from the Vulkan SDK and have all these functions defined without the application having to load them with vkGetDeviceProcAddr() or a utility library like Volk.

The Vulkan loader also supports some WSI extensions, which are necessary to display Vulkan applications. It's not clear to me exactly which WSI extensions are exported directly by the Vulkan loader. Based on the documentation at https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderApplicationInterface.md#wsi-extensions it appears to be the following:

• VK_KHR_surface
• VK_KHR_swapchain
• VK_KHR_display
• VK_KHR_win32_surface
• VK_KHR_wayland_surface
• VK_KHR_xcb_surface and VK_KHR_xlib_surface
• VK_MVK_macos_surface
• VK_QNX_screen_surface

The WSI extensions have progressed a lot beyond those initial Vulkan 1.0 WSI extensions. To get correct display functionality it's necessary for applications to use some of the latest WSI extensions, including the new maintenance extensions. Can the Vulkan loader support be updated all the latest WSI extensions that are included with Roadmap 2026:

• VK_KHR_present_mode_fifo_latest_ready
• VK_KHR_present_id2
• VK_KHR_present_wait2
• VK_KHR_surface_maintenance1
• VK_KHR_swapchain_maintenance1

[charles-lunarg]

These extensions have no commands and so can be ignored:

• VK_KHR_present_mode_fifo_latest_ready
• VK_KHR_present_id2
• VK_KHR_surface_maintenance1

These extensions do contain commands:

• VK_KHR_present_wait2
• VK_KHR_swapchain_maintenance1

What I would like is an explicit list in the spec for what extensions should and shouldn't be exported. There has been a export= field added to vk.xml, but it seems most if not all of the WSI extensions this repository exports do not have this field. In my opinion it was a mistake to export the WSI extensions as it causes confusion since there isn't an easy rule to use to know whether to expect a function to be exported or not. That said, I am perfectly happy to add these extensions if there is a clear 'rule' to follow. (whether it is explicit in vk.xml or a general list in the spec somewhere)

[charles-lunarg]

SI working group resolution: Defer to runtime/loader split, as exporting functions in the current architecture makes it possible to link to functions which may not be present when launching, leading to cryptic startup issues (namely, no clear reason why startup failed). With a runtime, applications can link to the runtime & the exported functions without worry, letting the runtime handle missing function support.