This is not an issue with the test but rather our implementation. D3D12 does not support anything like TRANSFER->TRANSFER barriers so that needs to be taken care of by the driver.
What's missing exactly on the Vulkan side? I'm guessing the CopyResource stuff doesn't finish before ResolveQueryData starts?
Ideally, we should probably do basic hazard tracking for overlapping TRANSFERs to buffers. Especially with queries I would expect apps to do lots of back to back resolves on the same target buffers. Could probably keep it as simple as possible, detecting the obvious patterns, and be conservative otherwise.
What's missing exactly on the Vulkan side? I'm guessing the CopyResource stuff doesn't finish before ResolveQueryData starts?
In Turnip vkCmdCopyQueryPoolResults happens through the different means than other transfer operations, so the result of vkCmdCopyBuffer could stuck in cache and therefor happen after vkCmdCopyQueryPoolResults. Thus we need a barrier to flush the cache.
So yes, we need TRANSFER->TRANSFER barrier.
This is fixed.
Nothing extracted yet.
I'm not sure about D3D12 but VK to avoid WaW hazard would expect a memory barrier between
vkCmdCopyBufferandvkCmdCopyQueryPoolResults. There is a test in Crucible that is based ontest_resolve_non_issued_query_databut has a barrier.At the moment
test_resolve_non_issued_query_datafails on Turnip.