* We handle non-suffixed promoted functions but assume that calling
forward to either the promoted function or the old KHR extension is
equivalent.
* By this nature we won't record which function the user called, be that
extension or promoted, it will just be reported as the core function.
* Remove KHR suffixes from function names, enums, etc for promoted
extensions when serialising/stringising.
* We report no support for Ycbcr conversions by snooping the physical
device feature query.
* Just to be safe, we support pass-through/ignore implementations of
most of the functions and pNext structs.
Disable the warning on 3rdparty files
${glslang_dir}/hlsl/hlslParseHelper.cpp
Disable the warning on files where fixing it would cause a non-OSX compile error
os/os_specific.cpp
* For unsigned integers this notices UINT16/32/64_MAX and displays as
a text string for easier consumption.
* Also for numbers over a given threshold we display them as hex instead
of decimal.
* Any struct with a pNext pointer gets a Deserialise function, to clean
up any dynamically allocated chains.
* The mechanism is as follows:
- On writing, walk the pNext chain (assuming there is one) and skip
any structs we don't care to serialise.
- When we reach a struct we do want to serialise, save a nullable (i.e
optional) VkStructureType* for it, then recurse and serialise the
nullable casted struct.
- If there is no pNext (or none we care about) we serialise a NULL
VkStructureType*
- On reading, we serialise the VkStructureType*. If it's NULL, rename
it to look like a void *pNext = NULL.
- If it's not NULL, use the structure type to serialise a nullable
struct of the right type, and recurse.
* The pNext chain is dynamically allocated, which is why it gets cleaned
up in the Deserialise() function.
* These extensions don't need any special support from us, and only
affect the SPIR-V consumption.
* The list of extensions is:
- VK_KHR_16bit_storage
- VK_KHR_relaxed_block_layout
- VK_KHR_storage_buffer_storage_class
- VK_KHR_variable_pointers
baldurk