* Two potential crashes here - one from the previous fix to #503, we
would double-release a refcount on an object that was set for write.
First we'd decrement the refcount when it was 'unbound', then again
trying to unbind it for write because the slot wasn't NULL'd. This was
just plain broken.
* The second more obscure one was when binding for read. If the external
object had no other refcount than the one in the binding slot, then
changing its binding would implicitly destroy it. However if the code
was setting the same object back again (ie. with the pointer they had
not reference to) then the refcount would drop to 0 then should be
incremented again to 1 when it's re-bound. However because the count
bounces off 0, the object is destroyed between being unbound and
re-bound causing pure virtual calls and other crashes when we try to
access it.
* The fix is first to check if we're binding something to its own slot
and skip it. Second we need to keep the new objects ref'd at all times
during the binding (in case we are e.g. performing an array bind which
moves the 1-refcount object from slot 2 to slot 3. It would be unbound
when processing slot 2, hit refcount 0, and then be added again when
processing slot 3).
* The D3D11 hazard tracking rules are then as follows:
- When binding a resource for read, if it is bound for write anywhere
then NULL is bound instead. If it's not, then any other read
references are preserved.
- When binding a resource for write, all other binds for read AND
write are forced to zero.
- The exception to the above: If a DSV is bound with depth read-only
then any read binds reading the depth channel remain bound. Likewise
for stencil read-only and stencil channel read binds.
- Special case: When binding RTVs and UAVs at the same time, if there
is a write overlap within that bind, the entire bind gets discarded
(including any non-overlapping binds) and state remains unchanged.
- When considering if a bind overlaps, it only overlaps if the view
in question covers an overlapping subresource range. In other words,
it is valid to have a write bind of mip 1 and a read bind of mip 0
at the same time (the classic case being mip generation).
* This commit fixes the second point, other write binds weren't being
NULL'd out. So binding a UAV to slot 0 then slot 1 in that order will
cause slot 0 to become unbound. Or binding to an RTV will unbind a
UAV or vice-versa.
Workaround inconsistent CreateProcessW string parsing by setting the
property to the Vulkan layer delimiter character. On some PCs it would
remove the quotes before sending to adb, and on others they would remain.
The quotes were interpreted by the Android loader as a layer name, and the
replay context's vkCreateInstance returned VK_ERROR_LAYER_NOT_PRESENT.
* When a barrier applies to only one subresource out of an image, it's
split into individual subresource tracking. There's nothing to merge
it back together again, so it remains split even if the subresources
go back to all being in the same state again. Simply checking when
fetching the frame-initial states if we can merge can be a big win.
* The cost of memcpy'ing data across to upload heap buffers for initial
contents and maps is significant, so for large buffers it's better to
allocate them GPU-side so we can do GPU copies.
* This also means that maps cannot happen directly, so instead while
reading we allocate a GPU-side copy of the map source data, and
perform a buffer copy instead.
* This means that even if the extension isn't reported in the string
for whatever reason, we still mark it available. It saves on checks
of (GLCoreVersion >= 43 || HasExt[foo]) all over the place.
* For some #extensions we can fallback to a lesser path (or just drop
that functionality - e.g. displaying cubemap arrays if there's no
extension for it).
* Of course if the capture used the storage functions during capture,
then they will still be used on replay. We are only removing extra
usage here for internal textures/buffers
baldurk