* When we need a SPIR-V pointer we box up a real pointer to a ShaderVariable,
and optionally column/scalar selectors if it's a pointer to a scalar within a
vector or matrix.
* For globals in opaque storage classes we'll allocate our own ShaderVariables
so that we can safely keep pointers to them. Otherwise IDs of temporary
pointers (from OpAccessChain) should always be a strict subset of the lifetime
of the ID it's pointing to, so we can keep the pointer around. The variables
don't move and are persistently allocated so they won't be relocated from
under us (we pre-allocate space for the IDs).
* Before passing back a ShaderVariable to the outside world, we evaluate its
current value. Thus pointers are presented as if they are just variables that
happen to update when their parent does.
* 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.
SV_PrimitiveID is only valid as a pixel shader input if there's either
no geometry shader, or the geometry shader emits SV_PrimitiveID. With
D3D11, the debug layer will complain but rendering will proceed. With
D3D12, the PSO fails to compile. For both APIs, pixel shader debugging
now checks whether this is true, and disables its usage if it isn't.
Added tests for various valid scenarios with SV_PrimitiveID.
With SM5.1, the operand for instructions like resinfo provide two
indices - the logical identifier and the shader register. Lookup the
identifier to convert to binding slot.
The logical identifiers, rather than shader registers, were used to
populate reflection info, causing the wrong slots in large descriptor
tables to be referenced for the pipeline state.
* 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.
Steve Karolewics