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.
The instance & physical device selector only allowed adding a single
extension at a time. This commit adds overloads for a vector of const
char*'s and a count + pointer pair.
Removes the subclassing of VulkanLibrary, bringing its logic into the VulkanFunctions
class. This resolves a weird linking issue which was causing hot-reloading of shared
libraries that statically linked vk-bootstrap to fail to unload correctly, preventing
reloading.
The commit also consolidates the logic in load_vulkan_funcs() into a single function
rather than having it be split in three, which only made the code harder to reason
about.
Also made vk-bootstrap look for `libMoltenVK.dylib` on apple platforms, in case the
application only has the MoltenVK shared library but not the loader (and the user
didn't manually load GetInstanceProcAddr from MoltenVK then give it to vk-bootstrap).
Turns out that was me being over eager in removing anything with 'desire' in the
name, and that for Swapchains there is a direct way to see the properties of the
swapchain after its creation, as vkb::Swapchain contains image count, colorspace,
present mode, and many other properties.
If the given extension is present, enable_extension_if_present will make
the extension be enabled on the device.
This fixes a gap in capability due to the deprecation of add_desired_extension.
This allows for a project with not-perfect use of macro defines across the
code base to not have different definitions for the dispatch tables.
For example:
```
PFN_vkCreateAndroidSurfaceKHR fp_vkCreateAndroidSurfaceKHR = nullptr;
void * fp_vkCreateAndroidSurfaceKHR{};
```
If VK_KHR_android_surface is not defined for whatever reason, the dispatch
table is still the same size, so other functions aren't affected.
The ability to request that some physical device or swapchain has certain features
but not require said features leads to confusion due to users having to manually
check if any desired request succeeded or not. Thus, this feature is being
deprecated, with eventual removal in the future.
Allows the tests to set the exact values vk-bootstrap will receieve
rather than require a real vulkan driver to be present on the system.
This is done by creating a `vulkan-1.dll` on windows that implements
all of the API functions, and on linux/macOS intercepts `dlsym` to
make it return the mock's functions.
VulkanSC was added to vk.xml and broke the generation script. This was an
easy fix, just needed to specify which API the version information should
use. Still, took the time to cleanup the code by running pylint and fixing
anything it warned about.
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.
