* We need to check for map writes even if the mapped buffer isn't the one that's
referenced by a submit but still overlaps it. We do this by moving to the heap
for all placed resources so any map to a buffer on a heap is checked as long
as any buffer bound to that heap is referenced.
* When debugging a pixel or doing quad overdraw we replace the pixel shader and
patch in our own UAV. Previously we were moving other UAVs out of the way that
were visible to the pixel shader, but this fails if a UAV is visible to all
stages and used in a vertex stage.
* Now instead for pixel shader inputs we pick a free space and use it. For quad
overdraw we pick an arbitrary high space to hopefully use the precompiled
shader, and if it's somehow not free we recompile the shader with a free
space.
* This is a test of a specific case of lazy serialisation, but in particular
D3D12 descriptors do some aliasing tricks for types to compress the data, so
repeated serialisation needs to be safe.
Fix a typo in a comment in D3D12_Descriptor_Indexing.py.
Fix UAV using a typed buffer view instead of a structured buffer view.
Fix SetDescriptorHeaps being called before ClearUnorderedAccessViewUint
* This is a stupid requirement as the quad overdraw shader doesn't use any
interpolators, but the D3D12 runtime complains and refuses to create a PSO
unless the PS has a matching signature. This works as long as the position was
the first output from the previous stage, but if it isn't the PSO fails to
create.
* To fix this, we take the existing shader and patch it by grafting the output
signature from the last stage over onto the input signature, and patching up
where the position is.
* There's not a good accepted terminology for this kind of event, and for
historical reasons 'drawcall' has been the accepted term, even though
that can be quite confusing when a dispatch or a copy is a 'drawcall'.
* This is particularly highlighted by the event browser filters where
$draw() includes draws and dispatches, but $dispatch() only includes
dispatches, it's hard to intuitively understand why $draw() matches all
of these calls.
* As a result we've defined the term 'action' to cover these types of
events in the same way that we defined 'event' in the first place to
mean a single atomic API call.
* These map more naturally to python tuples and are easier to wrap in and out.
* We also tidy up the FloatVecVal etc and standardise the members of
ShaderValue.