This attempts to optimize image usage such that we will fetch
new data out of our local surface cache using a blit rather
than requiring the data to be written to/from the backing
memory cache buffers first.
This allows us to avoid copying slices which we already have the
latest data available for (we previously would copy the whole
range if even a single slice was out of date).
Specifically, this allows games which use varying slices
of a Surface to have one backing image in vulkan, rather
than multiple images. If we see an image with depth 9
after previously having a compatible image with depth 3,
we upgrade the existing image rather than generating a
whole new surface.
Previously it was impossible to tell the difference between
two variants of the same surface in the Vulkan debugging
tools without digging deep into the allocated memory.
This is primarily to allow us to fully reset descriptors.
This is important as the validation layers were getting
confused about which resources were used in each frame.
This one was quite challenging to find. It only appears when
lots of staging buffers are used, and causes memory to be
read/written strangely incorrectly.
They were instead being written as soon as we processed
the buffer, which could confuse games into using resources
while the GPU still technically owns them.
For SPIRV decompilation, it is required that we use VertexIndex
rather than VertexId as VertexId is GLSL-only. This does cause
a behaviour change, but is rarely relevant.
Multiple surfaces with the same pitch but different widths are
all compatible with each other. It is necessary to ensure that
they are managed together.
When initializing the swap chain buffers, we inadvertently
were keeping the surface in general layout when clearing
instead of making it a destination first.
Usage of a singular queue from two places requires external
synchronization. It's far more prudent to just run the driver
in a separate queue context instead and let the driver work
it out.
This broke on newer versions of the Vulkan SDKs validators.
These did not fail on the driver as the driver seems to emulate
these objects on the CPU, but it is technically an error still.
