* Any uses of this for replaying subsections of the frame are to be
implemented under the replay driver level, as it's too onerous to
require that the replay driver be able to replay arbitrary subsections
or to communicate granularity up to the above layer.
* When the final header is ready we'll roll it into the source directly
rather than assuming the SDK is installed anywhere, and apply a local
change to get type-safety on 32-bit (which only works on C++). Similar
to the GL header's modification for a typed GLenum.
* Next step is to display VS and other stage inputs on the input panel.
* Also need to tidy up the fetching of highest mip/array slice etc to
use the same codepath.
* This fixes shader editing when the entry point file wasn't the first
in the list.
* Might need better detection of the main file than just searching for
the entry point substring - could produce false positives in other
files in a comment or #define or something similar?
* 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 will allow shifting to RenderMesh being run locally just by
the UI specifying the buffer and simple vertex specification, rather
than by relying on any local log properties (or replaying the log).
* The reasoning behind this change is that it becomes much simpler to
implement, rather than having to modify the draw to do what we want,
we just do an entirely custom draw based on a few properties - similar
to the texture rendering. This will help e.g. for writing a GL
implementation.
* The second benefit is that we can just transfer the buffer contents
across the network when replaying remotely, so mesh rendering can be
implemented even for remote replay - the last unimplemented feature.
* It could also be used similar to the image viewer in future, to
display mesh files.
* This will allow the adding of things like 'redundant api call' for calls
that have no effect, as well as potential problems like drawing with an
empty viewport, or similar things that are common problems. Reading out-
of-bounds on buffers etc is a good example of 'defined' behaviour that
is probably not desired.
* These heuristics could also identify potential performance problems.
* It also supports adding debug messages after log-load time, so you could
do an additional extra-strength pass, or do a detailed check of one
draw call (e.g. a broken draw, to try and figure out the problem). If
there are any unread debug messages, the status bar will flash and the
debug messages window will show a count as (N).
* This means when multiple fragments are writing to a pixel you can choose
precisely the one you want to debug, rather than the debugging always
running the approximately last fragment to pass
* Expand the abilities of the GetTextureData in replay drivers
to be able to resolve samples and render down to RGBA8 unorm
for file export to other programs.
* Greatly improve the ability to save textures - in theory any
texture format/type/dimension/etc should now be mappable in
sensible & useful ways to output formats.
* http://blog.selfshadow.com/2012/11/12/counting-quads/
* Quad Overdraw based on ScenePS4 from the revised implementation. The
colours are new, up to 20 levels. Picking pixels shows the overdraw level
* Available per-pass and per-drawcall, a pass defined the same way as in
the mesh view, drawcalls since last clear or RT change.
* List of events now passed through to RenderOverlay the same as RenderMesh
* For APIs where the shader namespace/bindpoint (which may be arbitrary
like 'the Nth texture resource' can be mapped, at each event, to the
actual API bind point where the object is.
* On D3D11 this is pass-through, on GL this returns the value of each
uniform.
* This also means GL shader reflection structures are properly immutable
and the variance in the uniform values is handled elsewhere.
* In future this might need to be expanded to support more complex binding
methods, where the mapping returns the resource rather than just mapping
to an integer bind ponit.
baldurk