Replay may be incorrect if a Vulkan fence was waited on with a non-inf timeout. about agi HOT 8 CLOSED

@johnplate could you please take a look at this one, please?

from agi.

@AWoloszyn Did you mean "if WAIT_ALL was not set"?
And there is no "infinite" defined for this function. Do we want to define a threshold for an "infinite" duration?

from agi.

Sorry, to be more clear.
If the timeout is not SUFFICIENTLY LONG* (where sufficiently long is defined as: both the trace and replay NEVER hit the timeout)

And if WAIT_ALL is NOT set. If wait_all is not set, then the returns may not be the same in replay.

from agi.

I do also consider UINT64_MAX nanoseconds to be sufficiently close to infinity that we typically treat it as such. Unlikely someone will be running for 500+ yrs

from agi.

Do we get any information, if the fence wait stopped because of a signaling e.g vkQueueSubmit or timeout?

Why don't we wait as duration of timeout variable?

from agi.

Lowering priority since it's not a blocker but still keeping it to P2 since we need to revisit this in the future.

from agi.

I would be worried about dropping the priority,
VkWaitForFences(VkDevice, VkFence, 42)
will simply not replay correctly (reliably)

from agi.

This has been fixed with #430

from agi.