* When we replace a shader in GL there are a few knock-ons: we need to replace
the programs that use this shader, and then from there we need to replace the
pipelines that use the program. We also need to beware of programs created
with glCreateShaderProgramv which refer to themselves as both a program and a
shader.
* Previously we'd look at the edited shader, then recurse and look at programs,
then recurse and look at pipelines. We'd try to remember which one replaced
which so we could undo it again.
* Now we just do this in subsequent passes since there is only a one-way
dependency: First replace the shader as needed, then update any programs and
either replace or remove replacement as needed, and finally update any
pipelines.
* On Vulkan and D3D12 it's simpler as we just have shaders -> pipelines but the
same principle applies.
* 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.
baldurk