Vkgetphysicaldevicefeatures2 Today

If you are writing Vulkan 1.1+ code, vkGetPhysicalDeviceFeatures2 is the only correct way to query and enable features. Use it. Chain it. Love it.

In the early days of Vulkan, querying device capabilities was straightforward. You called vkGetPhysicalDeviceFeatures , which filled a simple VkPhysicalDeviceFeatures structure—a large struct of boolean flags indicating support for features like geometry shaders, tessellation, or multi-viewport rendering. However, as hardware and APIs evolved, this simplicity became a bottleneck. Enter vkGetPhysicalDeviceFeatures2 : a core extension (later promoted to Vulkan 1.1) that fundamentally changed how developers query and enable features. This essay argues that vkGetPhysicalDeviceFeatures2 is not merely an incremental update but a necessary architectural shift towards extensibility, robustness, and future-proofing. The Problem with the Original Design The original VkPhysicalDeviceFeatures was a fixed-size struct. When Khronos introduced new features (e.g., shaderInt16 , descriptorIndexing ), they could not add new flags without breaking binary compatibility. Their solution was to create new VkPhysicalDevice*Features structs for each extension or core version—for example, VkPhysicalDeviceVulkan12Features . However, there was no standardized, type-safe way to query all features in a single call. Developers had to call separate functions for each extension or core version, leading to verbose, error-prone code. vkgetphysicaldevicefeatures2