Vulkan VK_KHR_swapchain extension behavior and present mode fallback inconsistencies

Vulkan 1.0 mandates the VK_KHR_swapchain extension, while Vulkan 1.1 promotes swapchain functionality to core; however, many drivers still expose the extension for backward compatibility, creating ambiguity about whether it must be enabled.

The specification does not define which present mode a driver should fall back to when VK_PRESENT_MODE_MAILBOX_KHR cannot be satisfied because the swapchain image count is below the driver’s internal minimum, resulting in inconsistent use of FIFO, FIFO_RELAXED, or undefined behavior.

Additionally, the behavior of vkAcquireNextImageKHR timeout when using MAILBOX present mode and delayed presentation is left unspecified, making vendor‑specific timeout handling unclear.

Which vendor‑specific fallback mode does a driver select for VK_PRESENT_MODE_MAILBOX_KHR when the swapchain image count is below its internal minimum?

Is the presence of VK_KHR_swapchain in a driver’s extension list still mandatory for Vulkan 1.0 applications, or can it be omitted without breaking compliance?

How is the timeout value for vkAcquireNextImageKHR determined when the present mode is MAILBOX and the application delays presenting?