* Unfortunately ID3D11Multithread::SetMultithreadProtected adds an auto-locking
thread safe mode for all D3D functions, so we have to add a check for it and a
lock to every context function. This will add a small amount of overhead even
when the mode isn't enabled, but it shouldn't be significant.
* We handle 4:4:4, 4:2:2, and 4:2:0, with packed, 2-plane and 3-plane formats,
for 8, 10, 12, and 16 bit depths.
* This covers most common formats but still leaves a few out - NV11, palettised
formats, V208/V408 JPG formats.
* The existing android cmake file doesn't work with newer NDK releases, so we
have to use the provided cmake file. It should work in NDKs as far back as
version 14.
* Most functions - including pthreads, malloc, free, etc are not safe to use in
signal handlers. So we use a simple spin-lock and manual linked-list to manage
our list of PIDs to wait on.
* 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.
* The new system contains the ability to export serialised data to a
structured form in memory - and conversion back to serialised bytes.
* This will allow offline transformations/visualisation of capture files
as well as more rich representations of API calls in the UI.
* Likewise it enables a number of optimisations such as the ability to
write straight from mapped API memory to disk via a compressor,
without any intermediate copies.
* Note that while this is public and uses std::string, because it's a
template with specialisations in a .inl the string never crosses a
module boundary - each including module has its own implementation.
* This will be used as part of the upcoming serialisation refactor.
* Some POD structs are still given ToStr implementations as we haven't
yet switched over the serialisation system to expect all structs to
have serialise functions.
* For the most part the interface is stl-compatible, but we have a few
little changes of our own for convenience.
* This class is still needed after deleting the C# UI, because we don't
want to pass C++ stl structs over module boundaries and possibly run
into hard to diagnose incompatibilities.
* 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.
* There was no good reason to have a flag indicating if the special
format was valid or not. Now it's a single enum, with a value
'Regular' indicating that the compCount/compWidth/compType fully
describe the format itself.
* This makes code patterns easier as you no longer need to check for
special then check for specialFormat, you can just test the type
directly.
* 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.
baldurk