Make the API take the struct by const reference by creating a local
variable that copies the struct, allowing the sType to be set correctly.
The need to set the sType is due to a deficiency in the first version
of these functions, which allows users to not set the sType. Making
users set the sType is difficult because it breaks user code without
warning upon updating the version of vk-bootstrap used.
The add_required_extensions_features function is templated, allowing both
vulkan.h and vulkan-hpp types to be passed in. Due to recent changes in
the generic features struct code, this stopped working. By casting the
sType explicitely using static_cast, it restores usage of vulkan-hpp types.
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.
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.
