* This isn't 100% reliable but it seems reasonably consistent that while
the first file in the streams isn't always the entry file, the first
name of a file in the list of names which map to files is. So we
re-sort by the list of names.
* This can happen in cases where the application syncs to the GPU after
using one set of descriptors from a pool, resets it, and then
allocates more descriptors out of the pool to use later in the frame.
* Since we allocate all descriptors up-front before the frame starts we
end up allocating more than the high-water mark, and running out of
room in the pool.
* Instead we just allocate duplicates of the pool as needed, as overflow
space, and then use those overflow pools to satisfy any extra need.
* Since we aren't displaying multiple instances we don't want to change
the instance selection, so instead of returning 0 return the currently
selected instance.
* Unfortunately some formats are *only* supported through VB fixed-func
inputs, and not through any other access (like texel buffer access).
* As a result, it's invalid for us to just create buffer views using
these formats to read from, so we will need to read-back the data to
the CPU, decode and unpack to another format that is supported, and
then re-upload. In some cases this might be extremely complex (e.g.
64-bit wide formats that have no easily supported fallback).
* In the meantime, we just re-write the format to R8G8B8A8_UNORM. It
will return the wrong data, but will at least not crash.
* Some memory types may not be compatible with buffers, so allocations
in those memory type indices we just don't create a spanning buffer,
as it won't be needed anyway to restore memory contents.
* OMSetRenderTargetsAndUnorderedAccessViews can 'keep' either RTVs and
UAVs and bind the other type when being called, but it's legal to
'keep' UAVs and bind more RTVs than were there before, or else 'keep'
RTVs and bind UAVs at an earlier start slot than before.
* In each of these cases, any conflicting older binds are unbound, so
for UAVs this means we unbound one or more from the start slot, and
move the start slot up. For RTVs we just unbind any old RTVs that
overlap with the new UAV start slot.
* Technically this is a backwards incompatible change, but captures with
these chunks before would have just been broken and fail to open, so
it's not worth bumping the serialisation version and adding backwards
compatible code for no reason.
baldurk