* With only a single semaphore we can only have one frame in flight and get
validation layer messages if we run faster than that and re-use the
renderStartSemaphore before the previous frame has completed.
* When the shader outputs a value larger than the texture format
supports, the use of a 32bit target for history targets resulted in the
Tex After for fragments showing a value larger than possible.
* The int/uint path for ConvertAndFillInColor was missing the clamping
step that the other path includes.
Output "ViewIndex" into the pixel shader hits array
Select the pixel shader input which matches the viewIndex to the passed in view
Ignore the view parameter if set to ~0U (rd.ReplayController.NoPreference)
Ignore the view parameter if any subpass has empty multiviews
Vertex shader output Red for view 0, Green for view 1, fragment shader does not use viewIndex.
Fragment shader output Red for view 0, Green for view 1, vertex shader does not use viewIndex.
Geometry shader output Red for view 0, Green for view 1, vertex and fragment shader do not use viewIndex.
Python checks vertex and pixel shader debug output against replay rendering output
DebugShaderInputs struct contains existing the parameters:
sample
primitive
and a new parameter
view
Default constructor for DebugShaderInputs sets the parameters to NoPreference (~0U).
* The compiler could compile an entry point "foo" into an export "bar". We use
the exported name in most places as that's guaranteed to be unique by the API
and used for cross-referencing, but when recompiling we pass the original
source name as in the debug info.
* 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
baldurk