0%
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.
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. vkgetphysicaldevicefeatures2