* We used to allow applications to call vkFlushMappedMemoryRanges on coherent
memory to manually annotate regions of memory that are changed in persistent
maps, thus avoiding the overhead of RenderDoc needing to check for changes on
each submit.
* Unfortunately this means that if the application calls flush wrongly then
changes will no longer appear, even though the application was completely
correct, if misleading, since by the spec behaviour vkFlushMappedMemoryRanges
is a no-op on coherent memory so incorrect calls to it make no difference.
* Since applications making use of this are rare or non-existant we just remove
the optimisation.
* DXIL's shape and necessity of pointers and relative addressing poses a
challenge for editing. Currently we pre-reserve all arrays and take pointers
to match DXIL's format and to allow edits to not require lots of index fixups.
However this is a challenge when editing as the arrays may resize as things
are inserted.
* The solution we take here is to copy all the arrays that will mutate to new
storage and reserving enough for the edits, *while keeping the old array
storage around*. We then assign all elements IDs, and after editing we do a
fixup pass to find any pointers that are pointing into the old arrays and find
them in the new arrays by ID.
* This means that pointers to the old storage remain valid and point to the
right object even after we've resized for editing, and we only fix them up
right at the end after all the edits so we can look up indices from pointers
again.
* This approach may not work indefinitely sadly, and it does require
conservative reservation. In future we might have to completely clone DXC's
data storage as well (arena allocated and new everything, with no arrays for
storage).
* We also allow GetPointerType to silently return NULL when no pointer exists,
as this will be useful for encoding when we want to check if a pointer type
exists.
* We now track the values in a simple array so getting value IDs amounts to just
getting an index in this array. This avoids the need to iterate in an llvm-
identical way to enumerate values. That does mean that we need to insert new
values into the array in the correct order, which isn't too bad.
* We cheat slightly with the attributes - we combine these on load, so we lose
information about multiple groups they may reference. So we save the groups
that we read from and use that to write the attribute.
* If we hit a fatal error during initialisation, the structured file pointer
still points at the temporary serialiser's structured file. It's not until we
finish loading that we swap it into the driver-stored file that we can safely
return and detach ownership of.
* In the old codepath for a valid existing window we'd create a cloned DC and
use that to pop with. However that DC is then released so we have created the
'stale DC' situation. This can cause problems with subsequent context
activations when we try to push/pop to populate GL hooks and fail to pop
properly as the queried DC is invalid.
* Normally we only check mapped memory when it's referenced during capture by
some binding, but for BDA we don't have bindings so we have to conservatively
check it every time.
* When using VS In we want to ignore the W component, but that already happens
explicitly for vulkan/GL in the shader. Mirror that same solution to D3D
instead of trying to force a 3-component format which may not be supported
(e.g. on AMD R16G16B16_*)
baldurk