* This typically means that the user hasn't checked correctly for SM6 feature
support before trying to upload DXIL shader, which will then result in
unpredictable behaviour or crashes on replay.
* During capture we detect this and flag it in the overlay text, and prevent
capturing. On capture load we fail to load if we detect such a PSO.
This changes the behaviour of Apply_InitialState for images with
BufferCopy type InitialState. Previously, the entire image was
transitioned to DST_OPTIMAL, along with a possible queue family
ownership transfer. Now, only the image subresources that are actually
copied/cleared are transitioned.
Change-Id: I92ab4d7160e99b81222231d1d974e707a55f7aef
This uses the new image tracking to avoid unnecessary copying of image
data when applying the initial state.
This change only affects image resets when all of the following apply:
- The image initial contents tag is `BufferCopy` (not
`ClearColorImage` or `ClearDepthStencilImage`),
- The image is single sample,
- The image is non-sparse,
- The image has `ImgRefs` data,
- The image has been completely initialized at least once, and
- VulkanResourceManager::OptimizeInitialState() is true (currently
disabled by default).
When all of these conditions are met, data will only be copied for those
image subresources which require reset according to the ImgRefs data.
Change-Id: I449eabfe969229fa64e233760aaadb489776ee23
* These features aren't supported by the underlying implementation.
* Triangle size we can feature-detect properly - by checking for geometry shader
support. Quad resolve should be supported but metal doesn't allow atomics on
images so we have to check specifically for a metal backend.
* This is necessary for e.g. the cube demo where it can create the image as
LINEAR in HOST_VISIBLE memory and then the image never gets dirtied, so we
don't properly create initial contents for it - instead only fetching the
underlying memory which is not technically legal.
* This seemed to cause crashes on some systems as libproxy links to libstdc++
and can then cause symbol conflicts between the static libstdc++ and the
system's libstdc++.
* libproxy itself cannot be statically linked, so the solution is either to
configure Qt without libproxy and break anyone who needs proxy support, or
stop statically linking libstdc++ and add a new dependency. At commit time
most distributions have at least g++-5's libstdc++ in their minspec so we can
require that - the main two that seem to fall short are Debian Jessie and
CentOS 7. Users on those systems will have to install a newer libstdc++ or
compile from source rather than using the binary releases.
* Even if a function isn't passed a global binding array as a parameter, we
still need to patch it in order to find any accesses it makes directly to
global resources just as we do in the entry point.
This field was recently added to the `ImageInfo` struct, but had not yet
been added to the `ImageInfo` serialization. Serializing this field
would unnecessarily break capture compatibility.
The `imageType` field was added to detect 3D images--depth slices of 3D
images are interpreted as array layers when accessed through a 2D image
view. This data is (almost) redundant, because 2D images must have
`extent.depth==1`, according to the Valid Usage for `VkImageCreateInfo`.
The application could create an image with
`imageType==VK_IMAGE_TYPE_3D`, but with `extent.depth==1`; we would
interpret this as a 2D image, but, since this image would have 1 array
layer and 1 depth slice, this doesn't actually cause an issue.
Change-Id: I3d53d942cbe8f240845a80f6e12a7cecfdd86967
* We also only use GIT_COMMIT_HASH where necessary to avoid rebuilding many
files for no reason, including splitting version.cpp out into a separate
project as we do with VS since otherwise changing its preprocessor defines
rebuilds the whole renderdoc project.
* At the same time, move the git hash to be internal only so we don't have to
try to link version.cpp into other projects like renderdoccmd or qrenderdoc.
This ensures that a thumbnail is created using the image from last
presented swapchain.
This swapchain, and the thumbnail still could be null. `CreateRDC` was
incorrectly asserting that the thumbnail contained non-null data. In
fact, `CreateRDC` already behaves correctly in the case of null
thumbnail data, so this assertion is removed.
Change-Id: I5b35463898029b0130fe9d8f39dda30e192deef6
The image info (layerCount, levelCount, sampleCount, extent, format,
type) was previously only available through `ImageLayouts`. This info
is now also stored in `ResourceInfo`.
Storing this in `ResourceInfo` makes this info easily accessible from
`VkResourceRecord`s representing `VkImage`s and `VkImageView`s. This
simplifies upcoming changes to the image tracking and avoids the lock
protecting the `m_ImageLayouts` map.
To simplify this duplication, a new struct `ImageInfo` is added here to
hold the image info in both `ResourceInfo` and `ImageLayouts`.
Change-Id: I390cbba4c3ce7b0bd6f004521497c21bf4c1e97f
This VkResourceRecord::resInfo being non-null was previously used as an
indicator that VkBuffer or VkImage resources had sparse bindings. Now,
`resInfo->IsSparse()` must also be true for the resource to be
considered as having sparse bindings.
Change-Id: Ia8a93ecb3248a682f71fcf6455d0d583ca129679
baldurk