* Mostly used for passing a progress float back during a long blocking
call like opening a capture or doing a copy.
* This is much more feasible for python to bind to.
* In several cases we just use a tiny lambda that updates a float anyway
since we can't push the progress directly into a progress dialog, but
need to let it query from a temporary in-between float.
* We enforce a naming scheme more strongly - types, member functions,
and enum values must be UpperCaseCamel, and member variables must be
lowerCaseCamel. No underscores allowed.
* eventId not eventID or EID, and Id preferred to ID in general. Also
for resourceId.
* Removed some lingering hungarian m_Foo naming.
* Some pipeline state structs that are almost identical between the
different APIs are pulled out into common structs. Where something
doesn't make sense (e.g. viewport enable for vulkan) it will just be
set to a sensible default (in that case always true).
* Changed scissors to be x/y & width/height instead of sometimes
left/top/right/bottom
* Abbreviations are discouraged, e.g. operation not op, function not
func.
* Previously each read and write would 1:1 become a send or recv call.
* Now we buffer writes and send in batch (or when a chunk finishes),
and every time we read we try to non-blocking read more data to fill
the buffer, to allow batching reads where possible without blocking
on data that will never come.
* Previously once we started loading a capture we'd blindly continue
until we loaded it (and then it's assumed to be successful), or we
crash.
* Now errors can be reported during serialisation and bubbled up to
abort the file load process. The next steps are to add error checking
in each function serialise before doing any replay calls to the API
with potentially corrupt data, and on top of that catching API-only
errors when the serialisation is (seemingly) fine, and propagating
those in a reasonable way.
* We also harden the serialisation a bit so that if it reads an
obviously invalid byte length for a buffer or array count, it won't
continue. It's still not perfect as the sizes could still be large and
invalid but within range, but it should catch the worst cases.
* 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.
* There's still an issue lurking that the compressed size is stored as
32-bit on disk, but at least now we don't store the uncompressed size
as 64-bit but track it as 32-bit.
* The serialisation is going to change Soon(tm) anyway so this
workaround should be enough for now, since hopefully compressed size
is comfortably below uncompressed size.
* There's no guarantee that the buffer is actually float data at all,
so printing it as such can cause float exceptions if the data includes
NaNs.
* This is not really useful anymore anyway, and if really needed the
float values can be manually converted from the hex data.
* If the machine idents differ in significant ways that we'd consider
it to be a different platform (currently just OS), and if so mark it
as supported but suggested to be replayed remotely.
* These are some leaks, some mismatched new/deletes and some uninit'd
values. Mostly the leaks are what we care about so that the replay
host can be kept alive for a long time rather than needing to be
constantly restarted.
* Also added a valgrind suppression file to suppress some of the false
positives I ran into while testing.
* The main improvement is that instead of just callstack resolving DB
and frame capture data, some arbtirary number of sections can be
included, for e.g. adding notes or saving the bookmarks or whatever
use the user wants.
* Sections (namely the frame capture data) can now be (de)compressed on
I/O, which leads to much smaller file sizes.
* Also the default internal alignment has changed from 16 to 64 to be
more future proof (I decided not to go with completely arbitrary
alignment).
* A path for loading previous version logs remains and will be removed
at some point in the future, maybe a version or two down the line.
* To align a buffer inside a chunk to a wider boundary like 32-bytes in
this case, the chunk needs to be aligned and the buffer within it also
needs to be aligned.
* The utility function accounts for the buffer serialised having a
uint32 length in front of it, so it pads out until that will be at
the desired boundary. This is a bit of a messy solution, but the
easiest way to ensure the padding is there while being easily
backwards compatible with old logs without the padding.
* D3D11 and GL serialise versions are bumped, D3D11 version is backwards
compatible, GL breaks compatibility.
* Note at the time of committing there are still some warnings in MS
headers that you might need to suppress in a couple of files.
* 3rd party code just has the warnings suppressed for ease of merging.
* The majority of warning fixes were for local variables shadowing
other locals, function parameters, or members. In most cases they
weren't a problem, but in some cases it was potentially dangerous!
* The real implementation can do more if it wants, and align to a larger
alignment, but we just return 64 to the program and align to that, which
satisfies the extension minimum requirements (and chances are no program
takes advantage of wider alignment anyway).
baldurk