* 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.
baldurk