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.
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).
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.
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.
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.
This lets applications see all the devices which meet a set of requirements
then pick whichever of these devices is most appropriate for them. The intent
is for applications that want to find all the suitable devices and let the
user of the application pick the physical device from a list.
A recent loader change results in NULL being returned for pre-instance functions
if the instance handle passed into vkGetInstanceProcAddr isn't NULL. This was
reverted but going forward this change will require updating applications.
- Internal tables are now populated through internal vkGetDeviceProcAddr rather than through passed dispatch table
- Device now has its own internal table as well.
- Cleaned up get_proc_addr functions and removed internal functions that are now held in a types internal tables.
Users can now ask for physical devices which support a specific 1.1 and 1.2
feature. VkBootstrap will then add the selected features to the enable list
in device creation.
