* Normal resources have a single memory bind that can be added to frame
references when the resource is. Sparse resources don't have that easy
single mapping.
* Calls to MarkResourceFrameReferenced with a 0 ResourceId aren't a
real problem, but we have to be careful when dirtying resources.
* We don't have to dirty memory that's sparsely bound as we'll dirty it
as soon as its sparsely bound. We do have to worry about making sure
that memory is correctly frame referenced.
* To do this command buffers track the sparsemapping structures (will be
created for all sparse resources) that are referenced underneath them.
Then at queue submit time the current sparse mapping is iterated and
all bound memory marked frame referenced.
* For most cases where a buffer is bound or similar, we can directly add
the sparsemapping from the resource record. For descriptor sets we
must do this indirectly - by marking any bindframerefs in the descset
record with a bit indicating that the associated resource is sparse,
then at submit time when iterating the bindframerefs, taking any with
the bit set and looking up its record to find the sparsemapping.
* Not supporting image transitions within secondary command buffers, and
doesn't support partial executes of secondary command buffers on the
replay side.
* Not sure when a renderpass clear effects should be available for an
attachment that isn't used in the first subpass. At the moment the
clear doesn't show up until the first draw, but that's not such a bad
bug even if it's our side rather than driver's.
* We can't analyse or reflect it at all, but we should at least pass it
through.
* Currently invalid but there will probably be extensions that allow
this, whether or not we'll allow them is a different matter.
* Currently I've decided to stick with the scheme of reading back from
mapped pointers where necessary to either compare or serialise. This
is because the bookkeeping for intercepting memory maps is quite
complex and right now it seems hard to justify as the overhead of the
readback is not significant enough to worry about. Unless we encounter
a case where the readback is hugely slower and frame captures begin to
take 10s of seconds longer, it's not justifiable.
baldurk