Called when loading captures in Iter_Test and Repeat_Load
Checks the consistency of EventIds:
Walk the actions to find all the referenced EventId's:
- Error if any EventId is duplicated
- Error if the EventId's are not contiguous (with no gaps)
Store SSA ID name strings in a container which is shared between the disassembler and the debugger.
The SSA ID name strings are guaranteed to be unique by appending the SSA ID value.
Do not use resource names for SSA ID names, only show resource names when a DXIL handle is created i.e. DXOp::CreateHandle, DXOp::CreateHandleFromBinding & DXOp::CreateHandleFromHeap
This means the debugger now has a unique name for each ShaderVariable generated.
Revert the ShaderViewer consistency changes which were only required because the DXIL debugger did not generate unique names for ShaderVariables.
Do not check before/after equals existing value for ReadOnlyResource and ReadWriteResource
In the DXIL debugger for resources the same SSA ID might have different names
RemoteServer timedout due to VK_Leak_Check taking too long before sending commands to remote server. Spawning a worker thread to keeping the remote server connection alive fixes the disconnection issue.
Similar to the validation that is performed in ShaderViewer UI
Disabled by default pass True to process_trace to enable the validation
Includes validate_shadervariable() and shadervariable_equal()
* Most of the main entry points that can fail with relevant reasons now has a
way of specifying a message to return with it. This message can be displayed
to the user to give more information or context about an error.
* 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.
baldurk