* 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.
* When displaying mip 0 of a texture at less than 100% zoom we linear sampling,
but we don't want to linear sample across slices. Adding a half pixel offset
in z ensures we sample precisely on the slice itself.
* 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.
* Pixel picking is a bottleneck, so do a render to a headless output and read
that back as a way of quickly checking that all of the subresource is OK at
once.
* We need to copy the external-facing m_RenderState into the partial command
buffer's state for partial replay, in case it was modified externally.
* Also when accessing the render state inside a drawcall callback we need to use
the command buffer's local state, not m_RenderState which isn't updated until
the replay completes.
* This helps catches cases where a discarded image is accidentally used and in
many cases may still have valid data. Particularly on Vulkan this is relevant
for DONT_CARE renderpass load and store ops.
* This is a leftover artifact from before we had general extended type support
and double was the only non-32 bit type we handled. Now we support most type
formats so doubles are just CompType::Float with 8 byte width
* E.g. on D3D12 we can debug DXBC shaders but not DXIL shaders. On vulkan this
will allow us to have the UI work better when encountering shaders with
unsupported capabilities or extensions.
* We preserve each API's interpretation of bit order for packed formats like
RGBA4 or R5G6B5 when displaying the raw data in the UI, but when we need to
proxy it or save to disk, we always transform to D3D's order as standard.
* This allows us to proxy them reliably because we always have a standard bit
order and APIs that need a different order transform when fetching data to the
standard format, or setting proxy data from the standard format.
baldurk