* This is kind of what VK_Parameter_Zoo is intended to test, but I don't want to
add conditional extension tests in there unless there's nowhere else to put
it, since it adds mental overhead to reading the code.
* We need to make sure we can still look up GPU addresses for buffers that were
destroyed during the frame, otherwise we might get the wrong contents for
descriptors.
* The spec says that you can only have one push constant range per stage, so
don't promote all push ranges to compute (as only one will be used in the
vertex shader).
Made the API filters inclusive, so that if any are checked, only the
selected ones are shown. If none are selected, then all tests are
shown as before. Moved the test name filter to the top pane, so that
it is always visible - before if you scrolled down in the test list,
it would be hidden. Added more room for test descriptions in the bottom
pane - long descriptions were previously truncated.
D3D11 may default to a different adapter than D3D12. For the sharing
test, both adapters must be D3D12 compatible. Tell D3D11 to use the
adapter that D3D12 is using to ensure compatibility.
Also fixed a memory leak in the test.
On laptops with integrated+discrete adapters, adapter 0 may not
support D3D12, so a default create device call will fail. Adapters
other than the 0th one need to be specified explicitly.
* It's required for replay applications to call InitialiseReplay() before doing
any work, and to call ShutdownReplay() once they're finished.
* This lets us do more heavyweight shutdown work before global destructors are
being invoked and the RenderDoc instance is being destroyed.
* Anything that needs to be shut down during capture still has to happen in
RenderDoc::~RenderDoc since we obviously can't get the application to call a
shutdown function in that situation.
* This fixes the case where no context is current on the thread starting and
ending the frame capture, but also all existing contexts are current on other
threads and can't be temporarily used.
* This struct might be passed without the parent bufferDeviceAddress feature
being enabled, e.g. if capture replay wasn't supported and we claimed no
support, or if there's really no support. We can't unconditionally enable
capture replay like we can with the extension structs (which are only passed
if the extension is available, and we only allow it to be available if the
feature is available).
Constant buffers store some additional state when parsed from DXBC
to make it easier to fix the match and know the correct size. The
debug trace still stores a simple array of CBuffers, but the shader
debug code provides a BindingSlot and uses the ShaderBindpointMapping
to find the logical identifier that shader instructions will use to
reference the constant buffer.
* The actual offsets will be overridden when client side buffers are used -
these marker values are left-over from client side buffers being present when
preparing a VAO's initial contents.
One notable high-level change is the behaviour of `StartFrameCapture`.
The previous implementation serialised the image state when
`StartFrameCapture` was called. The new implementation just sets the
"old" (beginnin go frame) image state (layouts/queue families) to be the
current state at this point; at `EndFrameCapture` the full image state
is serialised, including both the "old" (beginning of frame) and "new"
(end of frame).
Change-Id: I04c18c16a97e065c7a7d0edf058ba3f4803dcf45
`ImageState` tracks the state of images and their subresources.
This functionality was previously split between the `ImageLayouts` and
`ImgRefs` classes.
Change-Id: I3242417dacf73fe07765f9bcfd449599e373e10d
`ImageBarrierSequence` represents a sequence of batches of
`VkImageMemoryBarrier`s. The intended use case is setting image state,
which may involve a combination of layout transitions and queue family
transfers, and may require multiple barriers executed on different
queue families, in the correct order.
It is moderately expensive to execute a sequence of separate queue
submissions, with synchronization to prevent overlapping execution.
`ImageBarrierSequence` attempts to address this in two ways:
- `ImageBarrierSequence::Merge` allows separate barrier sequences (e.g.
on separate images) to be merged, so that, e.g. the first batches from
each of the barrier sequences are all run together.
- `InlineSetupImageBarriers`/`InlineCleanupImageBarriers` allow barriers
to be inlined into an existing command buffer, when possible. E.g.
to read the contents of an image, the barrier sequence may simply have
a layout transition to `TRANSFER_SRC_OPTIMAL` (assuming the image is
already on the correct queue family), and this can be inlined into the
command buffer before executing the copy, avoiding the need for an
extra queue submission.
Change-Id: I7f2edc650d9ff66871c9be5711789bfe33ca8c5e
baldurk