Fix timing mismatch issue for vkGetQueryPoolResults

[mizhen]

The problem

Some timing mismatch issue was observed when playing back a particular title's trace. vkGetQueryPoolResults returned VK_NOT_READY at playback time, while it returned VK_SUCCESS at the capture time.

The solution

The commit adds changes to handle the timing difference between capture time and playback time.

Result

Tested the target title with the build of the pull request, it fixed this issue.

[ci-tester-lunarg]

CI gfxreconstruct build queued with queue ID 274636.

[ci-tester-lunarg]

CI gfxreconstruct build # 4996 running.

[ci-tester-lunarg]

CI gfxreconstruct build # 4996 passed.

[mizhen]

This looks like you'd lose the timeout implemented in 75bc5b3. In order to keep that functionality, should this be converted to a time-based timeout?

Hi @bradgrantham, in the case mentioned in [75bc5b3], an infinite loop occurred in several D3D11 games running with DXVK. It seems that the query always returns VK_NOT_READY, indicating that an error has occurred prior to this call. It's possible that every following query for the same pool would also return VK_NOT_READY. Therefore, the time-based timeout value needs to be very short because it affects the frame rate.

Another approach is similar to the current vkGetFenceStatus handling. It uses command options --skip-get-fence-status or --skip-get-fence-ranges to skip the query. So, if there's no issue with vkGetFenceStatus, there's no timeout. If there's an issue with vkGetFenceStatus, the user can set the option to skip the call. We can implement the same handling, such as using --skip-get-querypool-results or --skip-get-querypool-results-ranges to skip the query for the case that an infinite loop occurred in a specific title. What do you think of this approach?