* If the usage flags on an image are different then the ICD might return
different memory requirements at replay time, which are no longer
respected by the offset/alignment that the application chose at
capture time.
* The real solution is to abstract the requirements and return our own
set of pessimistic requirements that encompass most hardware. For the
moment as a simpler solution we just add the same usage flags for both
capture and replay, if a flag is needed for either.
* 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.
* Certain panels like BufferViewer assume there is a current drawcall
at startup and not an invalid event ID like 0. Normally the event
browser is loaded first and sets the event ID, but if it's later in
the list this will break.
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.
baldurk