* Enter and shift-enter in the find text go forwarwd and backwards respectively.
* This replaces the previous system of selecting a direction explicitly and only
ever going in that direction when finding.
* We standardise on definitions: source variable names contain the full path,
and identify debug variable by full path. Debug variable members only contain
the child element - so foo doesn't contain members foo[0] or foo.bar, it
contains [0] or bar. Path walking happens when mapping source variable to
debug variable.
* This works just as well for DXBC but works much better for SPIR-V where debug
variables can be more complex.
* This lets the user override the default application font.
* Unfortunately Qt seems to behave inconsistently with font scaling from the
system, so we take the font size initially from QApplication::font() (which
doesn't always pick up the font size) and scale from there. While this might
cause some font scaling to be lost it does mean at least we have a consistent
scale, as otherwise you get some text scaling and others not.
Checks to enable debugging and pixel history are gated by the
APIProperties instead of whether the capture is D3D11. Shader
debugging for D3D12 is gated on a config option, which can be enabled
by adding "d3d12ShaderDebugging": "true" to the ConfigSettings
With SM5.1 and D3D12, constant buffer arrays can be declared which
are treated as an array of resources on the shader side, and a simple
collection of descriptors on the D3D12 side. DXBCDebug::GlobalState
handles the bridge between these by storing each array resource as a
nested ShaderVariable struct. Accessing the data for instructions
traverses the structure similarly. The shader viewer handles nested
resources and displays them in the appropriate tree view. In the
pipeline viewer, descriptors for CB arrays now indicate the array
index and correctly handle buffer offsets for viewing.
* The ShaderDebugTrace now only sets up the initial state of an opaque
ShaderDebugger handle.
* This handle can then be passed to a new function - ContinueDebug - to
iteratively return N more states. The number of states is implementation
defined and may be a fixed number or it may run for a fixed time.
* The states themselves no longer contain a complete snapshot of all variables,
but instead only the changed variables for that iteration. The changes are
stored as before and after value to make it easier to step forwards and
backwards (only the ShaderDebugState is needed to move forward or backwards,
you don't have to search back for the last set value of a variable to 'undo' a
change).
* The shader viewer shouldn't handle specifics of D3D bytecode, instead it now
works generally with whatever the debug and source variables are.
* VarType::Unknown is used for D3D registers which are typeless.
* cbuffer and input registers no longer have any names elided into them, they
are 'raw' registers. The source mapping provides the information of where they
come from as best as possible.
* Since we're now using source-mapping for constants, fix some source mapping
issues with arrays, nested structs/arrays, and matrix major-ness.
* Moving away from 'registers' explicitly being stored, we now have a single
variable array where the shader representation is responsible for allocating
it.
* In DXBC we calculate the number of each type of mutable variable (temps,
indexable temps, and outputs) and assign slots linearly.
* We also update some naming - high-level variables aren't "locals" since they
could be globals too, and debugging variables aren't "registers" but simply
the variables we use for debugging which may be more complex than float4 for
other APIs.
* The local variable matching by string name is unnecessary for this change
but will be more useful in future after further refactors where there isn't
a single list of variables to index into at the upper level.
* This avoids having the UI need to do a scan and expecting to find
"instruction:" on the start of a line.
* We also move the callstack to be stored per-step, and not in the line info
mapping.
* It's required for replay applications to call InitialiseReplay() before doing
any work, and to call ShutdownReplay() once they're finished.
* This lets us do more heavyweight shutdown work before global destructors are
being invoked and the RenderDoc instance is being destroyed.
* Anything that needs to be shut down during capture still has to happen in
RenderDoc::~RenderDoc since we obviously can't get the application to call a
shutdown function in that situation.
baldurk