* Even if new barriers aren't supported, it's still possible to use the creation
function and create them in any of the new layouts. In this case we can't use
new barriers to transition them out of that state so we have to pretend
they've already been moved out.
* There is no easy way to track the referenced resources in
acceleration structure builds, especially BLAS resource, as there is
no way to track how and when they will change.
Now with this change, we will track all the buffer resource
irrespective they are used in AS or not after the first call to AS
build.
* During recording of acceleration structure builds, add a callback to
track lifetime of virtual acceleration structure resource.
* Execute the callback at time command list execution to ensure the
order of correct acceleration structure on the backing buffer storage.
* Add Resource_AccelerationStructure as a new resource type
* Add D3D12AccelerationStructure class for virtual resource for tracking
acceleration structure lifetime.
* Since D3D12 doesn't provide a proper API-tracked way of seeing these
resources, we instead will track it ourselves and create a virtual
resource where valid ASs exist.
The CPU image state tracking does not know about state changes from a future command list which is submitted before the current list.
This leads to incorrect state transition when copying pixel data and getting incorrect data in the pixel history
* Previously we treated dynamic state as valid in a temporary state (when e.g.
pushing and popping state) only if it was valid for the currently bound
pipeline. However it's possible for an application to have a static pipeline
bound, set some dynamic state, then set the pipeline needing that dynamic
state before the draw. The state is temporarily invalid for a period of time
but eventually becomes valid, and if we're restoring that state we need to
restore the dynamically set state assuming it will become valid.
This behavior is correctly applied on Windows but on posix systems would fail to apply duplicate
entries that should be additive, such as multiple prepends. Previously only the last modification
would win.
* This prevents a potential deadlock/failed readback situation if the queue
we're submitting on at the time memory needs to be read is currently blocked
by a pending wait and can't execute more code.
* On Android the end-to-end latency of a single call is large enough that doing
a call per-instance in a draw with a high number of instances is a real
problem
* This can be a problem since copying by pitch * count can slightly over-read if
the pitch is larger than a row or slice, potentially reading into unmapped
pages.
* DecodeFormattedComponents converted everything to floats which were
then reinterpreted as int or uint via the unioned fields of PixelValue,
resulting in erroneous value display in PixelHistoryView.
* I've made a pixel history specific version of the format conversion
which treats the values the way the viewer expects.
Fixes validation error related to dependencies:
VUID-vkCmdDraw-renderPass-02684] Validation Error: [ VUID-vkCmdDraw-renderPass-02684 ] Object 0: handle = 0x61ee4f000000021b, type = VK_OBJECT_TYPE_RENDER_PASS; Object 1: handle = 0x1c2336000000021a, type = VK_OBJECT_TYPE_RENDER_PASS; | MessageID = 0x50685725 | vkCmdDraw: RenderPasses incompatible between active render pass w/ VkRenderPass 0x61ee4f000000021b[] with a dependencyCount of 0 and pipeline state object w/ VkRenderPass 0x1c2336000000021a[] with a dependencyCount of 2. The Vulkan spec states: The current render pass must be compatible with the renderPass member of the VkGraphicsPipelineCreateInfo structure specified when creating the VkPipeline bound to VK_PIPELINE_BIND_POINT_GRAPHICS (https://vulkan.lunarg.com/doc/view/1.3.261.1/windows/1.3-extensions/vkspec.html#VUID-vkCmdDraw-renderPass-02684)
baldurk