Previously, the code tried to make it possible to use vk-bootstrap with
Vulkan 1.0 headers. This makes the code complicated and left several paths
completly untested. Making Vulkan 1.1 headers allows for simpler code.
Note: This does NOT make a Vulkan 1.1 capable driver required to use
vk-bootstrap. This only requires that the headers used to build
vk-bootstrap are 1.1 or above.
Cleaned up the logic for handling when to use the core, the KHR, and when
not to use vkGetPhysicalDeviceFeatures2. This should make the logic easier
to follow with better names, and handle a few cases that were wrong, like
not caring if the extension is enabled by vulkan 1.1 is not.
If an application uses add_required_extension_features but also adds
a VkPhysicalDeviceFeatures2 to the pNext chain of VkDeviceCreateInfo,
this will now result in an error. The reason is that Vk-Bootstrap is
perfectly capable of adding VkPhysicalDeviceFeatures to the pNext
chain itself but only if the user didn't already add their own.
The XML added requirements which had multiple extensions be required.
This broke the existing autogen because it assumed there would only
be one extension required at a time. The fix is easy, split the
requirement string into a list then add it to the list of requirements.
- format feature flags should not be used, as set_image_usage_flags is a better alternative
- split format search in two phases (desired / best)
- explain usage of is_unextended_present_mode for basic validation
This allows the image views to be created with the same usage flags as
the swapchain. This necessitated passing in version information down
the object creation chain because to add the usage flags requires 1.1
to be enabled.
Previously, tests would always be enabled if the repo was the top
level project, which isn't desireable for users. This alters the logic
to, by default, only enabling tests when its a top level project, but
still allowing users to *not* enable tests by setting VK_BOOTSTRAP_TEST
to off.
Some alias types are not pure promotional types, and need to be excluded from the
code which replaces types with their alias.
This may be a stopgap solution for a larger underlying problem of not being able to
determine if an alias is promoted or not.
