LunarG/gfxreconstruct

ray-tracing captures are not tracked correctly

bradgrantham-lunarg opened this issue · 2 comments

When trimming, in state tracking (before the frame range) we write out the buffer contents for an AS directly rather than writing commands to recreate the AS in the state setup block. This is not guaranteed to work and I'm surprised that we sometimes see it succeed.

For vulkan this problem is addressed in the portable raytracing branch #1533

I closed above issue as duplicate, but still it contains very valuable insights:

It appears that gfx-reconstruct is relying on the opaque capture address obtained from vkGetDeviceMemoryOpaqueCaptureAddress to infer the corresponding vkDeviceMemory for a given address retrieved from vkGetAccelerationStructureDeviceAddress.
...
Opaque addresses should not be compared or offset against one another. A buffer's opaque capture address can be completely different from its BufferDeviceAddress

we need to keep in mind those address-spaces can/will be distinct.
thank you @dorian-apanel-intel for pointing that out.