* The serialise function handles fetching the ID on write, and looking
up the resource manager to fetch the handle on read.
* This allows us to do nice things like:
Serialise_SetConstBufs(SerialiserType &ser, UINT NumBuffers,
ID3D11Buffer *const *ppConstantBuffers)
{
SERIALISE_ELEMENT_ARRAY(ppConstantBuffers, NumBuffers);
// ...
}
And the array handling and serialise recursion will correctly iterate
and serialise the array as a series of ResourceIds, then restore it
as a series of handles.
* When opening a capture file, a format is now available to allow
easy import from another format without a completely different
interface. Only rdc files can be replayed, but any other file can
load and access structured data through the same interface.
* The replay initialisation and capture writing interfaces also use the
RDCFile instead of passing filenames or Serialisers around directly.
Driver initialisation parameters are now entirely private, and don't
need to be exposed - any agnostic metadata like thumbnail, driver, etc
are all accessed via the RDCFile container itself.
* Callstack resolution is now part of the container file, not the
back-end via way of its Serialiser.
* Importers/Exporters to other non-RDC formats are registered in a
similar way to replay/remote drivers.
* It is also then possible to construct an RDC file from thin air, by
creating an empty RDCFile container and filling it with data, then
requesting it to be written to disk.
* Since the initial states will all be written directly to the file
serialiser without intermediate copies, there will be no ability to
seek backwards to fixup chunk lengths.
* Instead all chunks will write an upper bound size estimate first, then
any padding is written at the end if they came in under the estimate.
* 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.
* The commits following this add a new refactored serialisation system.
As a balance between readability of individual commits and ability to
bisect/compile at interim steps, the individual API back-ends are
disabled in this commit, so that after the serialisation system is
committed the project compiles again as soon as possible.
* However this is of course not much use in itself as then the code
can't function usefully. The drivers are re-enabled as each one is
updated to the new system, so at least the codebase should stay
compiling, even if each individual API may not yet be functioning.
* Normally this wasn't a problem but in a few cases we were doing lots
of push_back calls and this caused horrible resize-by-1 behaviour.
* So instead we double the available count (if that's larger than just
satisfying the request).
* Hopefully these can be restored at some point, when the features are
implemented. For now where possible we remove options that are just
unavailable always, and selectively disable others when they may or
may not be available based on what API the capture uses.
* The DrawcallDescription children is mutable, so we don't need a
separate struct for that purpose in D3D11/GL where there's no side
data to carry along with (where draws are late-bound when submitted).
* This will be used in future to record the exact entry point the application
called, instead of just the function that we serialised (so calls aren't
falsely promoted to DSA variants, etc).
* Where the same enum value is used in multiple cases this then picks
the GL version. This is especially important when the same value is
used for radically different enum values.
* The new serialiser system will not handle the container file itself,
so we've separated it out to deal in sections and stream I/O to read
from and write to sections.
* We also add the ability to choose the compression scheme for a section
instead of always using LZ4. LZ4 will still be used on the fly for
fast write performance, but then RDC files can be re-compressed for
savings offline.
* This I/O will form the basis of the new serialiser - it will simply
read to or write from one of these I/O streams. Then that stream can
come from a file, go to a memory buffer, or go through a compressor
or decompressor transparently.
* It also allows a unified way of writing over sockets instead of
needing special socket helper functions.
* With this commit, the code isn't used aside from in tests.
baldurk