Notes
======
- Create a (hopefully) cross-backend performance statistics abstraction as part of FetchFrameInfo. This currently collects statistics about constant buffer binds, sampler binds, resource binds, client and server style resource updates (e.g. Map and UpdateSubresource), index & vertex buffer binds, and draws and dispatches. In my captures this covers approximately half of all API traffic. The rest is often shader sets, and then usual RS, OM, etc., that aren't currently tracked. During READING state parsing on the wrapped device context, record statistics about the calls and store them into the current frame info. We inspect objects occasionally to get things like their type for recording. It may be useful to expand this in the future to check bind types, etc. On the GL/Vulkan backends the stats data is never initialized and we display the same statistics data as before.
- Add a new statistics pane in the UI. A variety of shim arbitration/marshalling is provided to get the statistics data across the managed/native boundary. Removed the old statistics menu item. Currently the statistics pane is just a text log of various gathered data, with ASCII art (woo!) histograms. However in the future we would like to have image based historgrams as well as support for gathering statistics on a mask of stages, etc.
- Remove 'diagnostic' events (e.g. push/pop/marker) from the API call count as it distorts the API:draw call ratio.
- Add _First and _Count to ShaderResourceType and ShaderStageType for weak enumeration (weak due to int cast requirement).
- Provide utility functions Log2Floor for 32 and 64 bit types. These require OS specific clz, which are provided for Windows/VS and Linux/gcc/clang.
TODO
======
- UI toolkit based historgram, ability to set stages enabled for statistics, etc.
- Revisit necessity of gathering statistics across frames--apparently there is no multi-frame capture in a single log anymore?
- Revisit min/max/etc. gathering on the data--is there some way to improve this to not be so mechanical? Perhaps with field enumeration? However if moving to C++/Qt in future, possibly not a good time investment.
* 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.
* Tweaked flycam a bit too, but not much.
* Refactored the API/C# side camera classes to avoid exposing a ton of
stuff just to do relative rotations in the arcball via quaternions.
* The arcball lookat position can also be dragged with alt-click or
middle click.
* Also supports other elements as position not just magically-selected
"POSITION" element.
* 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.
* So RenderMesh doesn't pick up anything implicitly from the current
event, log, pipeline state etc - everything it needs is explicitly
provided by the config parameters (note this might include a buffer
generated by postvs data fetching, but the implementation now doesn't
need to care or treat it as a special case.
* 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 that all APIs pass byte string types. ALL strings everywhere
in the entire codebase must be assumed to be and treated as UTF-8 content
not ASCII.
* Gets rid of all the horrible %hs specifiers that caused warnings on
linux! Hooray.
* We convert to wide strings, or use wide characters, only when necessary
to use the Win32 API. Some windows specific code will stay in wide chars
just for convenience.
* Files are already serialised as UTF-8 strings for linux/windows binary
compatibility, so this change doesn't break backwards compatibility.
* You can choose which component will be used as 'position' when rendering
vertex inputs. Helpful if a position component isn't auto-detected, or
if you want to render UV co-ordinates onto the screen.
* Instead of fixed TEXCOORD0/Color options for solid shading onto the mesh
you can choose a secondary column yourself.
* Also the solid shading options are available on vertex output meshes as
well as inputs.
* 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.
* Also for float/unorm texture add an additional "resolved" option that
just does an unweighted average of all samples, which is the behaviour
from before (assuming that's what ResolveSubresource does).
* The explanation is in the FAQ but the short explanation is that most
data e.g. normal maps are conventionally displayed as if they contained
SRGB data, so RenderDoc does the same so things look as expected.
baldurk