This VkResourceRecord::resInfo being non-null was previously used as an
indicator that VkBuffer or VkImage resources had sparse bindings. Now,
`resInfo->IsSparse()` must also be true for the resource to be
considered as having sparse bindings.
Change-Id: Ia8a93ecb3248a682f71fcf6455d0d583ca129679
* We can't rely on the driver's reflection, since name information might be
stripped and the driver is within its rights to not reflect anything even if
we have names. Similarly queries by names etc will not work.
* Also we can't try to change bindings that are immutable on SPIR-V shaders -
UBO/SSBO bindings, transform feedback varyings, attrib and fragdata locations.
* Programs can't mix and match SPIR-V and GLSL, so when including our own
shaders in the overlay program make sure they match what the user's shaders
are.
* For mesh output, we need to patch the SPIR-V if it's a SPIR-V shader instead
of trying to use the GL XFB varyings set.
* The GL spec says that this is clearly allowed, but some buggy Android drivers
throw warnings or errors so we can add this harmless check on shutdown.
* Instead of patching e.g. PRESENT to GENERAL early, we keep the 'real' layout
even if that's UNDEFINED or PRESENT or whatever. We then do a last-second
patchup whenever we're actually transitioning images in vulkan itself, to set
the right layout.
* This requires us to do the patching in a few more places - anywhere like
texture rendering or initial states where we want to go from current state ->
custom state -> back to current state.
* This also allows us to more gracefully handle PREINITIALIZED image layouts. We
internally promote them to GENERAL as soon as possible, but keep them around
as PREINITIALIZED for display.
* This isn't technically true but it makes the code much simpler to align
offsets and sizes to it, so that then map flushes and invalidates all happen
on multiples of the atom size.
* Normally such images wouldn't be in the capture at all since there's no way to
reference them until after their memory is bound, but with "Ref all resources"
it's possible.
* We don't want to have glslang specific bits mixed in with general SPIR-V bits.
This is also preparing for moving some SPIR-V structs into common code that
can be re-used in new reflection/disassembly as well as editing.
* Otherwise internal resources like pipelines for mesh-output fetch can lurk
around in the creation info structures and cause problems when e.g. editing
shaders.
Benson Joeris