* In a previous update in 2021 many copyright ranges were truncated
accidentally, and some files have been copy-pasted with wrong years. These
dates have been fixed based on git history and original copyright messages.
* Given socket corruption or network errors these strings could contain
unprintable characters so we sanitise them reasonably. This also ameliorates a
potential security concern with arbitrary strings being written to a log, but
these connections are still considered trusted and users should not be
exposing RenderDoc ports to the internet.
* This prevents unnecessary conversions back and forth between rdcstr and const
char * when going through interfaces. In the OS specific layer this is rarely
an issue because most of the implementations don't convert to rdcstr, but it
is convenient to be able to pass in an rdcstr directly. The few cases where
there's an unecessary construction of an rdcstr is acceptable.
* A couple of places in the public API need to return a string from a global
function, so can't return an rdcstr due to C ABI, so they still return a const
char *.
* Similarly const char * is kept for logging, to avoid a dependency on rdcstr
and because that's one place where unnecessary conversions/constructions may
be impactful.
* Mostly moving includes from common headers to cpp where possible, and removing
includes of the whole thing where only enums or rdcstr etc are needed.
* The primary user is the main logfile itself, but it's useful for debugging
purposes to be able to log to a file and still open it externally in a viewer
without having the logging code take exclusive access to it.
* If these static locks are destroyed before other things at shutdown, logging
may crash. We can just leak them since they should survive until process
shutdown (where it's fine to leak)
* When needed on windows we convert to/from UTF-8. For most places this is easy
enough, the callstack processing is now moved to store most data as UTF-8 in
the first place.
* This makes post-mortem debugging easier. It's only active while a remote
server connection is running, so e.g. it will miss crashes of the remote
server itself, this could be improved by adding a margin where it will still
check for messages after the connection is dropped - perhaps on a separate
thread.
* Reported by Coverity Scan - most of these are not an issue and a
couple of them are coverity getting really confused (like seeing a
pointer being assigned to NULL and a count to 0, then a few lines
later declaring that a loop 0..count will dereference the pointer).
* However it's harmless in all cases to add a bit of robustness to keep
the analysis happy.
* With the log append setup, printing lines and newlines separately can
lead to them being interleaved between multiple processes writing to
the same log.
* This way the lines in a print could still be scattered, but without
over-allocating to modify newlines in place (which would be more
expensive too) this can't be fixed, and both multi-line prints and
multiple processes writing a lot of log prints are rare.
* We need to use file locks to ensure the last process knows it can
delete the log, as well as delete any inherited file descriptors when
forking to launch a new executable.
* To accomplish this, tracking the single logfile handle is now part of
the OS-specific code instead of common logging code. It makes little
difference either way as we don't support multiple log files.
* This gives a little nicer syntax, a bit better type safety, and also
reflects better for SWIG bindings. Overall it's a minor change but
better.
* We don't update the C# UI at all, since it's soon to be removed and
not worth the effort/code churn.
* For now so we're ABI compatible with C#, all enums are uint32_t, but
that is an obvious optimisation in future to reduce struct packing.
* We avoid 'None' as an enum value, because it's a reserved word in
python so will cause problems generating bindings.
* Using OS-specific append writing functions instead of simple fopen/
fwrite/fclose we can guarantee that multiple processes writing to the
same log file won't trash or interleave their log output.
* To make the logs readable the PID is now included along with the
project/timestamp.
* After that, we make sure that when we launch a program we set the
output log to the same file as the parent UI. This keeps all the logs
together and removes user confusion over which logfile is needed.
* We also move all of RenderDoc's temporary files under a RenderDoc
folder in the temp folder, instead of scattering the files in the root
* This suppresses lines like "RenderDoc v0.31 x64 (...) loaded in replay
application" which are only useful for the logfile and not for actual
user output.
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.
baldurk