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.
* Also the PipelineStateViewer will set its current 'sticky' API type
to the common pipeline state, so that when a log isn't loaded we can
still get API-specific properties that match the last API used.
* Depth is not cleared, only colour buffers.
* This uses the same definition of pass as the quad overdraw overlay,
which isn't quite the same as the auto-grouping passes (which allow
for varying colour binds being grouped together). It only counts up
to the last draw where the outputs were different.
* 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 means that the timeline bar will show use as read/write/clear etc
and that right clicking on textures in the texture viewer will show
the events where that texture is used for rendering, for reading, and
so on.
* The option will enable monospaced fonts for all data displays, like
the list of events, API calls, etc as well as pipeline displays, entry
of filename/directory in the capture window and many other places.
Pure UI labelling etc mostly still stays as a serif font.
* A few sizes of controls were tweaked (like headers in the pipeline
windows) so that they didn't just barely overflow with the larger
font.
* While looking at this, it became obvious that buffer viewers and
constant bufferviewers should always display in monospaced regardless,
so that has been changed.
* What gets listed as a 'drawcall' is a bit fuzzy - previously it was
drawing calls, dispatches and clears, but you could make a good
argument for these to be included as well. As a semi-experiment, these
calls are now included and will be listed in the event browser.
* Other calls can change resources like direct buffer or texture uploads
and Map() type calls, but these remain as API calls listed between
draw calls. Again this is mostly an arbitrary distinction.
* D3D11 logs are backwards compatible, GL logs are not (although it'd
be relatively simple, GL logs will likely break backwards compat soon
anyway, so not worth supporting it now only to break it soon).
* 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.
* 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).
* 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.
* 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
* While replaying the initial chunks, we're doing edit type operations but
we haven't serialised out the binding operations in between, so in this
state we do the bind-to-edit binds ourselves.
Michael Vance