* 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).
* It identifies some potential overflows which we know likely won't happen, but
the fixes are harmless.
* Some issues are definitely bad, though not actual bugs.
baldurk