* It's possible that a frame capture could copy from a query and then reset it,
without then recording something valid into the query. Then the next replay
the copy would be unavailable and if WAIT_BIT is set that would lead to a
device lost.
* We already fill out queries with dummy valid data on create time, so now we
record any queries that are reset and re-fill them with valid data again.
* Having a single subresource (range) is a common case, so avoid allocating
storage in an array for that, only switch to the array when we have more than
one range to store.
* We don't expect contention on this, the only time it will contend is when
actively capturing a frame between updates and submits reading the descriptor
contents, so we penalise that case while making the background case faster -
since a spinlock is 'free' to take when there's no contention.
* If an application allocates from and resets descriptor pools at very high
frequency the overhead of freeing and reallocating those descriptor sets can
be high. Instead use the descriptor pool as a pool for children and look up
the freelist first for an existing descriptor set before trying to allocate a
new one.
* This is still accurate, what we're missing is "read data as int, then cast to
float" which is represented by setting 'floatCast' to true. A normalized cast
or interpret is accurately represented by saying the input is snorm/unorm
typed.
* When we roll over from one binding to another due to descriptor count being
larger than a single binding, we need to update the frame reftype since it
might go from storage to sampled or vice-versa and so change from read-only to
read-write.
* While active capturing we might do significant work to flush coherent mapped
memory regions and prepare initial contents for postponed resources that are
about to be write-referenced. We need to do that before submitting the actual
work to the queue or else the contents may be corrupted.
* We track memory bindings to see which regions of a memory object are only used
for tiled images, and discard any writes in case this was accidental detection
of changes by the GPU which we don't want to replay. In the case of aliasing
if there's linear and tiled resources then we still replay the writes.
* Note that we have to take a slower path involving a copy since we can't
serialise straight into memory in this case, so applications should avoid
mapping memory behind
baldurk