This matches how debug variables are matched
This supports source mapping to resources which are a child member of a ShaderVariable i.e. an array element
* Undefined values are still 0xccccccccc, since that value can propagate through
operations. But source variables mapped directly to an OpUndef are displayed
in a more semantically clear way.
This sets the offset of the VariableTag for array members in the watch
window. This ensures they are sorted correctly when displayed.
This also adds sorting by sourceVarIdx if the memebers are
globalSourceVars which fixes the sorting in the High Level Variables
window for built-in Variables
* In a previous update in 2021 many copyright ranges were truncated
accidentally, and some files have been copy-pasted with wrong years. These
dates have been fixed based on git history and original copyright messages.
* 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
* 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.
* 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.
if members.size() == 0
rows * columns must be between 1 and 15
type must not be Struct
if members.size() > 0
type must be Struct or Unknown or ConstantBlock
rows must be 0
columns must be 0
then recurse and check construction of each element of members array
Step Forwards: first appearance of a variable must have "before" = {}
Step Forwards: not-first appearance of a variable "before" must equal currently known value
Step Backwards: first appearance of a variable must have "after" = {}
Step Backwards: not-first appearance of a variable "after" must equal currently known value
* This shifts from reporting from the old style bindset/bind to the new system
of only referencing by shader interface and index (independent of binding
model).
* The vulkan shader debugger re-uses the replay interface to cache descriptor
access and descriptor contents in a fashion friendly to interface-index
lookup.
* The enums are given after compute, to preserve indices for the normal vertex
pipeline.
* Mesh dispatches are considered a new action type, rather than being bundled
into the `Drawcall` type. This will allow them to be distinguished by API
backends as needed. The UI treats them as drawcalls
* We apply this universally even though it's not relevant to D3D11/GL. It means
a couple of empty array entries but it should not cause any significant
issues.
* Shader messages will be identified by group and thread as with compute
shaders. For mesh shaders there is an additional subdivision to identify them
by task group, since each task group can submit a grid of mesh groups.
MakeExecuteAction already sets tooltips for each QAction it creates,
but these are not used in a QMenu unless the toolTipsVisible property
is set to true.
* This distinction unfortunately does not exist in SPIR-V so we have to carry
around this metadata ourselves. Rather than allowing free specification of
tools based on API, instead pretend that Vulkan and GL SPIR-V are separate
format, and duplicate all SPIR-V tools to handle "both" types. This allows
appropriate tool selection based on the encoding.
* When searching for the start of a range of instructions mapped to a single
line when stepping backwards, we need to ignore instructions that don't have
any debug info because they will look like a 'different' smaller stack.
* We store the compiler used (when known) in shader debug info and use that to
select the compiler for editing as even higher priority than the default for a
given language/encoding combination.
* We also ensure that for known tools we add the input and output parameters
last, after any custom parameters, so that they are always present regardless
of what the user puts in.
* This allows us to more accurately display those that have been modified since
the last step, when a source-level step covers multiple instruction-level
steps.
* We also do our own sorting of source variables based on how recently they were
updated. This applies in both directions, so stepping backwards and
'reversing' a variable change will also count as a recent update.
* Since the source vars data doesn't change for a given instruction, we can pre-
calculate it and save time on re-calculating per-state.
* Note callstack *can* change per-state on SPIR-V where the same instruction can
be reached by different flow paths, so the callstack remains part of the per-
state data.
Jake Turner