Vulkan 1.3 Core Dynamic Rendering and VK_KHR_dynamic_rendering Extension Compatibility Across Driver Versions

Answer

No. Requiring Vulkan 1.3 as a minimum instance version is not required to use dynamic rendering, but it is the simplest way to avoid dual-path logic. If you need to reach devices that only expose VK_KHR_dynamic_rendering on Vulkan 1.1 or 1.2, keep a dual-path query and enable flow.

Confirmed facts

• Dynamic Rendering is core in Vulkan 1.3 via VkPhysicalDeviceVulkan13Features.dynamicRendering. It is enabled by chaining that struct in VkPhysicalDeviceFeatures2.pNext when creating a logical device.
• The same capability was provided as the optional device extension VK_KHR_dynamic_rendering with VkPhysicalDeviceDynamicRenderingFeaturesKHR.dynamicRendering on Vulkan 1.1 and 1.2.
• vkEnumerateInstanceVersion limits what the loader will expose. Requesting an instance version higher than the loader supports makes vkCreateInstance fail.
• Enabling a feature struct the device does not support, or requesting an extension that was not enumerated, triggers validation errors and device creation failure.
• Core and KHR feature structs have different names and pNext chains. They must not be mixed for the same device.

Likely explanation

Current desktop drivers commonly expose Vulkan 1.3, making a 1.3 baseline practical for desktop-only titles. Mobile and older integrated GPUs often expose dynamic rendering only via VK_KHR_dynamic_rendering on Vulkan 1.1/1.2. The choice between a single baseline and dual path therefore depends on your target hardware distribution and acceptable test coverage. A single baseline simplifies code and testing; a dual path increases reach at the cost of two enable paths.

Safe query and enable steps for Vulkan 1.1/1.2 support

1. Instance creation: call vkEnumerateInstanceVersion if available, otherwise assume 1.0. Create the instance with the highest version the loader supports, typically VK_API_VERSION_1_3.
2. Per physical device:
   • Read physicalDevice.apiVersion.
   • Query core features via VkPhysicalDeviceFeatures2 with VkPhysicalDeviceVulkan13Features in pNext. If apiVersion >= VK_API_VERSION_1_3 and dynamicRendering is VK_TRUE, use the core path.
   • Otherwise enumerate device extensions with vkEnumerateDeviceExtensionProperties. If VK_KHR_dynamic_rendering is present, query VkPhysicalDeviceDynamicRenderingFeaturesKHR via VkPhysicalDeviceFeatures2.pNext and check dynamicRendering.
3. Device creation:
   • Core path: enable no extension name for dynamic rendering. Chain VkPhysicalDeviceVulkan13Features with dynamicRendering = VK_TRUE in pNext of VkDeviceCreateInfo.
   • KHR path: add "VK_KHR_dynamic_rendering" to enabledExtensionNames. Chain VkPhysicalDeviceDynamicRenderingFeaturesKHR with dynamicRendering = VK_TRUE in pNext. Do not chain VkPhysicalDeviceVulkan13Features on a device with apiVersion < 1.3.

Verification notes: log the instance version returned by vkEnumerateInstanceVersion, log physicalDevice.apiVersion, log whether VK_KHR_dynamic_rendering is enumerated, and log the value of dynamicRendering from the queried feature struct. Attempt vkCreateDevice with only the detected feature struct and confirm no validation errors.

One missing diagnostic detail that changes the recommendation: what proportion of your target user base is on mobile or pre-1.3 drivers where VK_KHR_dynamic_rendering is the only option. If that share is negligible, a Vulkan 1.3 minimum is reasonable; if it is material, keep the dual path.