Vulkan VK_KHR_swapchain extension behavior and present mode fallback inconsistencies

Direct Answer

There is no vendor-specific fallback for VK_PRESENT_MODE_MAILBOX_KHR. The Vulkan specification does not define one. MAILBOX is optional and must appear in the list returned by vkGetPhysicalDeviceSurfacePresentModesKHR before you request it. If your swapchain imageCount is below the minImageCount reported by vkGetPhysicalDeviceSurfaceCapabilitiesKHR, creation violates valid usage; a conformant implementation must reject it or a validation layer must report it. It does not silently become FIFO, FIFO_RELAXED, or any other mode.

VK_KHR_swapchain is not promoted to core in Vulkan 1.1. It remains a WSI device extension dependent on VK_KHR_surface. Any application that presents to a surface must query the device extension list and enable VK_KHR_swapchain. Omitting it breaks the presentation contract on implementations that advertise presentable surfaces, regardless of the Vulkan API version.

The timeout passed to vkAcquireNextImageKHR is entirely application-controlled; MAILBOX does not change its semantics. Pass UINT64_MAX to block until an image is available, 0 to poll (expect VK_NOT_READY if none is ready), or a finite value (expect VK_TIMEOUT if it elapses). Delayed presentation can exhaust outstanding images, so acquire may wait until a queued present completes and releases an image.

Confirmed Facts vs. Likely Explanation

Confirmed: no silent present-mode fallback exists; invalid image counts are invalid usage; VK_KHR_swapchain is still required for presentation; and acquire timeout behavior is independent of present mode.

Likely explanation: if you observe FIFO behavior when you expected MAILBOX, the cause is usually application-side fallback logic, an active layer or override, or a driver bug—not a specified vendor fallback. Because exact driver behavior varies, verify on your target implementation.

Steps to Resolve and Verify

1. For the exact surface and presentation queue family, call vkGetPhysicalDeviceSurfaceCapabilitiesKHR and vkGetPhysicalDeviceSurfacePresentModesKHR. Record apiVersion, device extensions, minImageCount, maxImageCount, and whether MAILBOX and FIFO are enumerated.
2. Choose a present mode only from the enumerated list. If MAILBOX is absent, use FIFO as the portable fallback.
3. Set imageCount to a value within [minImageCount, maxImageCount] (treat maxImageCount == 0 as no upper limit).
4. Select an explicit timeout strategy and handle results distinctly.

Example query pattern:

VkSurfaceCapabilitiesKHR caps;
vkGetPhysicalDeviceSurfaceCapabilitiesKHR(physDevice, surface, &caps);

uint32_t modeCount = 0;
vkGetPhysicalDeviceSurfacePresentModesKHR(physDevice, surface, &modeCount, nullptr);
std::vector<VkPresentModeKHR> modes(modeCount);
vkGetPhysicalDeviceSurfacePresentModesKHR(physDevice, surface, &modeCount, modes.data());

Timeout outcomes:

Enable validation layers during swapchain creation to confirm that an imageCount below minImageCount is rejected rather than silently altered.

Missing Diagnostic Detail

If you are seeing unexpected FIFO behavior, the one detail that changes the recommendation is whether validation layers were active during swapchain creation. If they were not, enable them and repeat the test before attributing the behavior to a vendor fallback.