* This means these will spam errors if anyone is using a feature level
10.x or below device without ps_5_0 support, but that's unavoidable
and not too important (in release it'll just be some log spam).
* The implementation needs the fine dFdx/dFdy variants, which are only
available in GLSL 4.50 and above. Without that support we fall back
to the normal dFdx/dFdy which are implementation dependent. In my
quick test on nvidia it so happened that it was still fine, but that's
not guaranteed.
* Since we decode the visual colours into an integer by looking them up
in the overdraw ramp rather than re-running to get an integer return,
we make some invisibly subtly different colours above the highest
overdraw colour, and use these to tell overdraw levels above 20.
* glsl and hlsl custom display shaders are kept separate, and only shown
for the appropriate log type.
* The little snippets added in the shader editor aren't updated yet, and
none of the pre-defined shader constants are filled out.
* It's only used in glRasterSamplesEXT, so it's an error to either
glEnable/glDisable it or check via glIsEnabled. It's already handled
properly to RasterFixed, so just drop it from the enabled bits.
* We call LazyInit() in the first swapchain create, and on replay log
initialisation. This is guaranteed to be before we use it (on replay
it will always be hit, and in program if there's no swapchain, we
won't use the debug manager for text rendering). It's also late enough
that it won't be triggered for every device while enumerating or such.
* This saves on errors and other spam (and internal compile errors if
an older d3dcompiler.dll is used) when none of these resources are
used. We only use what's necessary for font rendering.
* If hardware support for feature level 11 isn't present, fall back to
the WARP software rasterizer. This will support everything needed, but
it certainly won't run well.
* There are loud warnings - I added a debug message to the debug errors&
warnings window so the status bar will indicate that, and it's in the
title.
* At most once every 3 weeks there will also be a message box pop up
when loading a log, to remind the user so that it isn't forgotten, as
for obvious reasons this is not the intended use-case (hopefully once
per 3 weeks isn't too often to be annoying).
* Client code can enumerate the IDs of counters that are supported -
some of these will be general, some will be IHV specific. It can also
request descriptions of the counters to determine the type of data or
units. This can be used to 'discover' counters that aren't hard
coded into renderdoc. I'll want to at least reserve IHV ranges so that
counter IDs are globally unique, and ideally IHV counters will also be
predeclared where possible.
* Also the refactor removes some ugly rdctype::array use outside of the
replay layer and replaces it just with std::vector, which is a nice
bonus.
* We stream-out or transform feedback the whole instanced draw at once,
producing a buffer containing all N instances in one. Then when the
client requests postvs data, an offset into the buffer is calculated
(in 1/N chunks) and carried through everywhere.
* Since we were using the offset to indicate where the system position
output lay for since-last-clear auto drawing of meshes, we rearrange
the output attribute order so system position is always first in the
list.
* Also since-last-clear now doesn't include the current event, but does
include any previous instances before the current instance.
* This might be an nvidia bug but I honestly don't know what the syntax
for varyings is, and the spec seems vague (it just says 'user-defined'
variables). This system/heuristic works on NVIDIA and AMD though, so
it'll have to do for now.
* This will work in case the binding order changes between two impls,
and it also works if copying program state between two programs that
might have different UBO/SSBO sets.
baldurk