Add a column that shows the parent marker for the event range (by default the end event ID)
Add an option to prevent combining resource usage across markers (group by marker)
The tooltip for a resource usage entry contains the full marker path
* It is common for drivers to dead-code eliminate resources and they will not
show up in reflection at all and will not have a binding. For these we will
still encounter them when debugging so need to ensure we handle that case.
* This unfortunately makes a previously illegal/error-checked case silently
continue, so we add API-specific asserts.
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
* If program or shader names are very long then combining them can cause
problems with how wide the widgets get. Splitting each element into a label
that can wrap around and be truncated individually produces better behaviour.
* This is almost completely worthless as it seems at least NV and amdvlk both
actually crash the GPU on this instruction, meaning there's no way to get it
to the shader debugger. But on other drivers like radv, or maybe if this is
fixed in future, this will be useful.
* For this reason it also can't be tested automatically.
* We shouldn't require 'pure virtual' functions in CaptureViewer implementations
in python, so detect when the derived class methods point to the base class
pass-throughs, and skip them in that case.
* Unfortunately the new upcoming debian has made the really poor decision to
actively *delete* the pcre package, breaking any programs depending on it even
at build time. As far as I can see it's still available in most other common
distributions.
* Users could easily build it themselves but would have to install it system
wide for it to be picked up. This kind of dependency absolutely should not be
something the build system has to set up itself but when distributions make
poor choices we have little choice but to adapt somehow.
* This will be optional in many cases but for some situations might be required
when type information is not implicitly available in the descriptor store.
Generally it should always be available unless the descriptor store is being
viewed 'blank' purely from its contents with no other context.
baldurk