* Some drivers have issues doing normal work while queries or XFB are active,
and there's no reason to keep them active indefinitely since they might not be
closed by a subsequent draw replay (if multiple draws are spanned and we
select a draw in the middle).
1) A depth image might have different number of samples, tested on a
case where there is a resolve attachment on vkCmdEndRenderPass, but
the depth attachment is multisampled.
2) HasMultipleSubpasses should take into accoun the case when there is
no renderpass, for example post vkCmdEndRenderPass
* There was a race condition where the newly created HWND surface could
be resized during swap chain creation. This causes a
`VK_ERROR_DEVICE_LOST`, but is very timing dependent.
* The fix was to finish the resize, via `ResourcePreview::setActive()` /
`QWidget::show()` before scheduling any async functions that could
create a swapchain, namely `IReplayOutput::AddThumbnail()`.
- Separate the pixel history copy pixel shader into two separate
shaders, one for colour copy and one for depth
- Allocate and update descriptor sets on demand
- Add another compute shader for pixel history depth copy
* We can have a RW lock so that once deferred slots are allocated there's little
contention, but we must ensure that allocating a new slot doesn't race with
access to a slot on another thread.
* If we don't do this, the application could create a buffer/memory and use it
then destroy it and create another one in the same capture. The driver could
assign the same opaque capture address to both buffers even though they
"overlap" in the capture because they don't overlap in actual execution.
* Slightly artificially extending the life of the resource to the end of the
capture ensures the driver gives them non-overlapping device addresses.
baldurk