LunarG/gfxreconstruct

ray-tracing captures are not tracked correctly

bradgrantham-lunarg opened this issue · 2 comments

bradgrantham-lunarg commented

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.

bartosz-muszarski-arm commented

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

fabian-lunarg commented

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.

  • 👍1