* There was a gap between stopping active capturing (meaning newly created
buffers are given an extra refcount) and releasing the extra refcount. Any
newly created buffers in that gap would still be released but that would mean
one of the application's ref's is removed, possibly destroying a buffer by
mistake.
* Instead we keep a specific list of buffers that we're extending so that we
know that the buffers we release are exactly those we gave extra refs to.
* We still detect the precise same git commit in the android build and skip
recompiles, which is useful for building android once on one platform and
sharing it with other host platform builds.
During the first callback we use an occlusion query and a stencil
attachment to count the fragments. For that callback create a new
framebuffer that is equivalent to the original, except that it
substitutes the original depth stencil attachment (if there was one)
with a different one where we can count the number of fragments.
Previous code breaks for the case where there are multiple colour
attachments. For these replays also set colorWriteMask to 0, so that the
color information is not written, since we are using the original
attachments.
Also stop and resume renderpass when doing a copy on
vkCmdBeginRenderPass.
The assignment of logical identifiers is not guaranteed to match the
order of appearance in the shader bytecode. Adjusted D3D12_CBuffer_Zoo
to exercise this for testing.
* This doesn't test every edge case, but it is a simple smoke test that ensures
any format can at least get consistent accurate results out.
* Further work is needed to test the different failures, overdraws, primitive
IDs, and all the other specific checks in the history.
When importing captures from v1.6 and before, the order that image
subresource states are listed in the capture differs from the order
expected in `ImageState`. This change sorts the subresources into the
correct order before importing.
Change-Id: I1bb1420bc79e39ba8e1fb2e932307a218878e1c2
While we always use an 8 byte storage within renderdoc, the KHR
storage can be of multiple size & type.
The issue was that we were storing a counter in double but then
reporting the type in uint.
To fix this use the KHR storage type to figure the renderdoc type. The
byteWidth size remains always 8 bytes within renderdoc.
This fixes a performance regression when loading captures from <=v1.6
(before the new image state code went in). The code to import the old
image state information was incorrectly discarding the frame ref
information, forcing the images to be reinitialized on every replay.
In old captures `ImageRefs` chunk is processed, creating `ImageState`
objects that only contain `refType`; then `BeginCaptureFrame` processes
the `ImageLayouts` info, to construct a new `ImageState` object,
containing the layout information. This `ImageState` was overwriting the
`ImageState` from the `ImageRefs` chunk, discarding the `refType` info.
This change merges the `ImageState`s from `ImageRefs`, where each field
of the merged image state comes from whichever `ImageState` had a
non-undefined value for that field.
For new captures, this change should be safe, since the image state
should be undefined when the `BeginCaptureFrame` chunk is processed, so
the `MergCaptureBeginState` call will just take all the state fields
from the `ImageState` stored in the `BeginCaptureFrame` chunk.
Change-Id: Id2252edb6382bd02bc0236b77c7cca667e97bf29
This is needed for Vulkan Pixel history, where we need to know render
state at current point of time for a command buffer during callback
replay.
Modifications:
- Removed m_pDriver and m_CreationInfo members from VulkanRenderState,
instead these are accepted as arguments to member functions.
- BakedCmdBufferInfo state is now full VulkanRenderState
baldurk