* Also adds support for arrays in the type info
* We allow register mapping aliasing since it can happen during function calls
if the same local is declared in two places - the PDB doesn't seem to add a
gap for the 'parent' variable unfortunately.
* CheckUnsupported handles all known compatibility GL functions and extension
functions, so this would only be true for an unpublished or completely new
extension. It might break, but if it's an internal function call it's better
to pass it through.
* We emulate the readback by creating an FBO, binding the texture, and reading
it back. Unfortunately a texture with type GL_ALPHA can't be bound to an FBO,
so the readback fails.
* As a fix, we do a manual draw to a temporary R8 texture with the same
dimensions, then read it back the conventional way. This is wasteful but the
only way.
* In future there may be other formats that can't be bound to an FBO but aren't
compressed.
* VK_EXT_shader_stencil_export and VK_EXT_shader_viewport_index_layer are
shader-only extensions that don't affect the postvs code.
* VK_EXT_depth_range_unrestricted lifts a restriction that we don't care about.
* 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.
baldurk