* 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.
* We are really looking for persistent memory leaks here not fluctuations in
memory use. There are too many false positives from memory usage increasing up
high part-way through the iterations and then reducing down for the final
iteration, which could be many lazy or deferred things running and completing
over time.
* Even though a clear feels like it shouldn't dirty the image, it still means a
write to the image which we need to be sure to save as initial contents.
* This will let us run multiple windows (and multiple threads) relatively
easily.
* The hammer is fairly big, we move some things into the window that don't need
to be there necessarily if we have multiple windows on a single thread, but it
keeps things simple.
baldurk