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
This allows much simpler analysis of queue families. E.g. in
`vkCmdPipelineBarrier`, we can differentiate between queue family
release and acquire operations; we can also mark used subresources as
implicitly acquired by the command buffer's queue family.
Change-Id: I3e90ea1be5938781bdec675e69918b5f2bc49a49
Three new fields are added to `ImageInfo`
- `VkImageType imageType`: this is used to distinguish 2D and 3D images,
to correctly handle access through 2D image views.
- `VkImageLayout initialLayout`: this is the `initialLayout` in which
the image was created (`UNDEFINED` or `PREINITIALIZED`). This is used
to correctly initialize `PREINITIALIZED` images (See: TODO).
- `VkSharingMode sharingMode`: This is needed to correctly generate
queue family transfers, because we must *not* generate queue family
transfers for images with `CONCURRENT` sharing mode.
This also refactors `SwapchainInfo` to use `ImageInfo`, rather than
duplicating some of `ImageInfo`s fields.
Change-Id: Ic42077c382e4055cb27af069045c46eacbd122cc
`ImageSubresourceRange` is a common representation of subresource
ranges of Vulkan images, including `VkImageSubresourceRange` and
`VkImageSubresourceLayers`.
Additionally, `ImageSubresourceRange` can represent a range of depth
slices--this is used to model access to 3D `VkImage`s through 2D
`VkImageView`s, where the view array layers are mapped to the image's
depth slices.
Change-Id: Id08329b499a02817ccd3487bdbb9c1bb0f86262a
This represents a (sub)resource for which no usage info is available.
It should be conservatively assumed that such a resource needs to be
re-initialized before each replay (and this behaviour is reflected in
`InitReq()`).
Change-Id: I12235a6cb1c4b2e3e21bed8834653ec6a3aea009
* We use HasWrapper() to deduplicate D3D12 objects which must not be created as
duplicates, but we need to ensure that checking for existing wrappers and
adding a new one all happens atomically with respect to other checks.
* We can't easily restore the application's context if the DC that was current
has been released. Instead we check to see if the last known window is still
valid - if so, we get the DC handle from it. If not then we assume that
rendering to the application's context setup would have failed so we bind our
own backdoor window (but with the application's context still).
baldurk