* If they're autogenerated then unfortunately the locations in a shader can
change over edits depending on what the shader is doing. We need to remap
across this as well as composing that onto any capture-replay remapping.
When initializing VkDeviceMemory resources, some regions may be cleared
using vkCmdFillBuffer, rather than having initial data copied.
vkCmdFillBuffer requires that the interval offset and size are multiples
of 4.
This change aligns all of the intervals containing the `FrameRefType`s
used to determine the initialization requirements for VkDeviceMemory.
This alignment is done as the intervals are loaded so that the
initialization (before the first replay) and reset (before subsequent
replays) use consisent alignment.
Change-Id: Icb1a1ba5fc0045fc4ec1ccbfe9caad06154f2338
* This is only lightly tested and may break heavily. It is disabled by default
and must be explicitly enabled.
* In particular this is only known to work for Wayland use at capture time.
Wayland on replay is still unsupported. Known issues include: EGL pbuffer
surfaces are not implemented on Wayland, Wayland cannot get window dimensions,
and there are hangs/failures with GL and vulkan presentation with Wayland.
* If a pipeline doesn't statically access a descriptor set, the corresponding
descriptor set layout in its pipeline layout can be essentially anything and
it doesn't have to match the actual descriptor set bound at a draw. It's just
ignored.
* Rather than check for static access ourselves we take advantage of another
fact - when the descriptor set is bound it must be compatible with the set
layout from the bind call's pipeline layout. If the pipeline *does* statically
use the descriptor set, its pipeline layout must be compatible with the bind
call's pipeline layout for that set.
* So the end result is that we can safely use the bind call's pipeline layout
for iterating over bound descriptors, secure in the knowledge that it's always
valid for that data, and if the pipeline uses it then it's also valid for the
pipeline.
* On AMD's driver at least the reflection for a separable vertex program
includes all declared outputs even if they're statically not written in the
vertex shader. However trying to use these as XFB varyings fails.
* Unfortunately this makes it impossible for us to use our typical reflection to
determine what outputs to write, so instead we make a last ditch attempt to
get things working and link the non-separable program we're about to use for
XFB and reflect that again, then use the reflection to remove items from the
varyings and replace them with gl_SkipComponentsN.
baldurk