* Debugging shaders with UAV access could(likely will) have side-effects on
those UAV contents, so when ContinueDebug needs to fetch UAV contents we
should replay back to before the draw to fetch them.
* This replay only happens once per ContinueDebug, and UAV contents are cached
globally so we only do it once per UAV that's accessed, so the impact is low.
* Previously we hinted loading both the old LunarG metalayer and the new
combined Khronos layer. Since only one was a 'real' layer this was safe and
would allow us to enable validation anywhere without needing to enumerate
available layers.
* Unfortunately a new loader version makes it an error to specify the
VK_LAYER_LUNARG_standard_validation for loading! So it is completely
impossible to be fully compatible. We have no choice then but to follow the
loader/SDK's path and have a hard backwards compatibility break.
* This means the validation won't be enabled anymore for anyone on SDK from
early 2019 and before.
* Normally SetEventID is synchronous and blocking, and will stall the UI while
it is processing. However we can at least pop up a progress dialog and allow
the UI to function (if not be interactive due to the blocking progress dialog)
when some other long-running task is delaying the processing on the replay
thread.
* If the last refcount on a python lambda/temp function is released when a
wrapping std::function is destroyed in a C++ invoke, we can't destroy it
safely. Instead we queue up that decref and process it the next chance we're
able (which is either when the current execution finishes for a python shell
execution, or on the next function call which handles extensions).
* When we use the wholeMemBuf from a dedicated allocation it may actually be
smaller than the whole allocation, and we need to be careful not to overuse
it. Keep a separate size for wholeMemBuf which can shrink if the buffer is
smaller.
* This fixes a bug with granular command buffer resetting. On vulkan we assume
each command buffer owns the entirety of the pages it uses, so they can be
reset all together. However there's nothing to stop an application from
allocating from the same pool on the same thread interleaved to two command
buffers. It's unexpected because of the threading rules but perfectly legal.
* In this case we need to ensure that the command buffers have disjoint sets of
pages because they may not be reset together and one may be in used while
another is reset and even re-recorded over. This can't be achieved with a
single allocator, so instead we split the pool (that owns/provides/frees
pages) from the allocator (that grabs whole pages and suballocates for
chunks).
* When resetting pagesets in a granular fashion from the chunk allocator, it's
possible to almost (or completely) exhaust a page but not have it be bumped
out of the free list, then one more new full free pages is pushed. When that
free page is exhausted we'll retire it then assume the next one is usable -
but it is still not valid. We need to loop until we find a page with enough
space.
* During capture we hold the transition lock for writing, so we need to try to
lock that first (if we're going to) before locking the queue's lock. Otherwise
another thread could come in and get the queue's lock while we're holding the
transition lock, then we deadlock against each other.
baldurk