Closed werman closed 1 year ago
Could you tell us more about the platform you're on and maybe give us the settings you're using to capture? We haven't seen this here and I wonder if we're missing a particularly common case.
Well, I'm using gfxreconstruct to capture a trace (of d3dretrace + DXVK) on Linux + RADV driver while simulating Turnip (Mesa's VK driver for Adreno) with Vulkan-Profiles, then I'm replaying the capture on actual board with Adreno GPU. All of this is for quick and easy testing of Turnip with d3d11/d3d9 games.
I'm capturing without any additional options beside enabling the layer.
I'm replaying with gfxrecon-replay --remove-unsupported -m rebind --sfa
.
We haven't seen this here and I wonder if we're missing a particularly common case.
From what I see in code, virtual swapchain is used by default, and with -m rebind
it should always result in VulkanVirtualSwapchain::CreateSwapchainImage
being called.
@locke-lunarg , when you get a moment could you look at this? Is it possible that since VulkanRebindAllocator
defers allocation until use that we need to force allocation in VulkanVirtualSwapchain
?
This issue also happened on Windows. But because it happened during release, I didn't figure it out.
@werman Please test PR https://github.com/LunarG/gfxreconstruct/pull/853 to see if it gets fixed.
@werman We merged this fix. Please let us know if dev
still shows this issue.
Ah, sorry, tested and it is indeed fixed. Thank you!
@werman Thank you.
https://github.com/LunarG/gfxreconstruct/blob/e39cf66520e4085aa4bfc72e51a009c9a3405a71/framework/decode/vulkan_virtual_swapchain.cpp#L98-L100
This frees invalid
VkDeviceMemory
handle with value~0
, which leads to a crash in the driver.The
VirtualImage
for swapchain is created viaCreateSwapchainImage
, which callsAllocateMemoryDirect
->VulkanRebindAllocator::AllocateMemory
, which setsVkDeviceMemory
tokPlaceholderHandleId
, which is~0
.