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.
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.
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.
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.
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.
The autogen accidentally took a reference instead of a copy, so all the aliases
were using the same data as the base type, leading to incorrect macro guards.
In addition, any aliased function would use the base funciton's types, leading
to incompatibilities when compiling with older headers. The chosen solution is
to always use the alias type if it exists.
Lastly, NVX was added to a blacklist, no functions from NVX extensions will be
generated, since they are experimental in nature.
- Replaced GenericFeaturesPNextNode's set function with a template constructor.
- Moved validation asserts for extension feature structs into source.
- Dispatch table now generates in UTF-8.
