* It turns out there are some corners of the spec where *only* an unsized format
is valid, and a sized format that's at least as large will break, so the only
way to fix this is to preserve unsized formats.
* This does mean things could break if the driver at replay-time makes a
different decision about what sized format to pick, but hopefully that won't
be an issue.
* If the capture requires an external queue but never uses it (e.g. it has some
resource that's on another queue and either incorrectly accesses it on the
wrong queue or doesn't access it at all but still somehow has it referenced)
we need an external queue - if we didn't find one in the capture by the time
we get to ApplyInitialContents() we fetch it ourselves.
* We also fix up device creation info if we've remapped the queues into
duplicates by having the replay with fewer queue families than capture.
* It's valid to have overlapping buffers on a heap, which could end up with
overlapping ranges.
* It's impossible from the API to tell which buffer an address came from if
there are multiple possibilities, but any of them will be technically correct,
we just might display a different buffer than the user expected.
* The problem with storing resource pointers in descriptors is that it can be
invalidated without detection - a kind of A-B-A problem - if the resource is
deleted and then another resource is allocated with the same pointer.
* Descriptor creation in D3D12 is extremely complex and there are many ways a
resource could become incompatible with the descriptor metadata struct.
Detecting all possible ways a new resource could be incompatible is not
feasible.
* As a solution, we store the ResourceId which we know is immutable, serialise
via the pointer, and keep the live ResourceId on replay. If the resource was
deleted, the serialisation will fail because we look up the pointer at the
point of serialise, and a deleted resource will end up being NULL.
* To try and abstract this away and avoid potential confusion with the
ResourceIds, we make the descriptor contents private and provide accessors.
* Any time the replay types serialisation change, the remote server becomes
incompatible. We're not going to add backwards compatibility to that system,
so we need to break it every time.
* Really the version should be bumped any time renderdoc_serialise.inl changes,
but we don't have an auto-incrementing revision to use.
* This measure the number of samples that pass the depth/stencil tests -
In the case of early tests, this means it doesn't account for shader discard before writing.
baldurk