search

LunarG / gfxreconstruct

Graphics API Capture and Replay Tools for Reconstructing Graphics Application Behavior
https://vulkan.lunarg.com/doc/sdk/latest/linux/capture_tools.html
MIT License
401 stars 115 forks source link

--sync for Capture #1043

Open andrew-lunarg opened 1 year ago

andrew-lunarg commented 1 year ago

An option for capture:

    GFXRECON_SYNC

...which does at capture time what --sync does at replay: "Synchronize after each queue submission with vkQueueWaitIdle."

This would let us capture a more correct trace from apps which issue a sequence of command with the potential to delete or reset resources still in-flight on the GPU. An app could work fine on its own and at capture but then fail or fail to validate at replay because replay issues the commands faster than the original app did and thus wins (or loses) a race against the GPU.

Rather than fixing this at replay, doing it at capture lets us have a conservatively good trace that the app couldn't have made on its own. Once we have an app that's known to need --sync to replay safely, going back and recapturing with GFXRECON_SYNC is less error-prone and more automatic than shipping the instruction to use --sync around with the binary trace file.

We probably want to record the wait idle into the capture, which is equivalent to forcing --sync on replay.

We might want to do a vkDeviceWaitIdle to account for multiple threads bashing on different queues in a potential future multithreaded replay.

per-mathisen-arm commented 1 year ago

There is another way of solving this, at least for the use cases we've seen. The app will usually have to check the fence status before being able to reuse the resource, so if we delay the successful return value from vkGetFenceStatus() a user-defined number of times, we can also delay the resource reuse by the same number of frames. We plan to make a merge request implementing this feature soon.

JinyiChenUofT commented 2 months ago

There is another way of solving this, at least for the use cases we've seen. The app will usually have to check the fence status before being able to reuse the resource, so if we delay the successful return value from vkGetFenceStatus() a user-defined number of times, we can also delay the resource reuse by the same number of frames. We plan to make a merge request implementing this feature soon.

Hi Per, may I kindly ask has the feature you mentioned here already been implemented?

per-mathisen-arm commented 2 months ago

We made a pull request for this feature in https://github.com/LunarG/gfxreconstruct/pull/1155 but internally we have an improved version, so lets see if we can update this pull request. I know LunarG have been reluctant to merge this since it seems like a somewhat esoteric feature, but if there are more users of this maybe they will reconsider :-)