* 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.
baldurk