Features 11, 12, and 13 structs used to set the sType manually for the user.
That was turned into an assert which inadvertently broke users code. This
is being reverted.
Allows users to enable features if they are present, getting back a bool
telling them whether the feature is supported and will be enabled on the
device.
Also:
* Removes redundant VkPhysicalDeviceFeatures2 struct in vkb::PhysicalDevice.
* Adds test copying of details when creating a VkDevice so that test can check
what features were actually enabled on the device.
* Creates GenericFeatureChain struct for managing pNext chains.
* Allow multiple calls to set_require_features by combining the fields
This allows the set_required_features_11/12/13 to take a reference instead
of a value. Applications should set the sType, vk-bootstrap shouldn't be
doing that for apps.
vulkan.h includes platform specific headers that cause non trivial build
overhead. Because vk-bootstrap doesn't make use of any platform specific
API's, it can move over to vulkan_core.h.
This *MAY* break users of the library who were depending on vulkan/vulkan.h
including other headers, like windows.h. But because the benefits outweigh
the drawbacks, it is a good change.
Generalize the mechanism to not enable function pointers based on the current header
version, due to VK_EXT_discard_rectangles adding functions not present in the original
extension.
Types that are promoted get turned into aliases, but the dispatch table was missing
these types. This was due to a simple mistake of mixing up the alias with the type
being aliased.
This commit fixes issues that prevented clang-cl & clang from being distinguished
on windows, resulting in improper command line arguments being used.
CMAKE_CXX_COMPILER_FRONTEND_VARIANT is the proper way to distinguish clang from
clang-cl, which have different command line options.
Adds extensive integration tests that exercise the various ways of finding
the Vulkan-Headers.
vk-bootstrap should now use the Vulkan-Headers or Vulkan::Headers targets if
they were already defined (such as is the case of FetchContent), and will
look for the VulkanHeaders package and Vulkan package as a fallback, and will
FetchContent Vulkan-Headers directly if that fails.
This should make integration seamless with the various ways vulkan-headers
is acquired.
The vk-bootstrap-vulkan-headers target was dropped in favor of directly
linking to Vulkan-Headers (creating a target by that name if none exists).
The API of vkGetLatencyTimingsNV changed, which causes compilation failure due to
the generated code using the newer API while the Vulkan-Headers may be for the old
API.
The fix is to just disable the function if the headers are too old. While this does
limit the usage, because its from a new extension, there shouldn't be a huge impact.
