replay: Add --serialize-queue-submissions option#2827
replay: Add --serialize-queue-submissions option#2827antonio-lunarg wants to merge 3 commits intoLunarG:devfrom
Conversation
antonio-lunarg
added
the
approved-to-run-ci
antonio-lunarg
force-pushed
the
antonio-serialize-submissions
branch
from
4666252 to
b5d10b2
Compare
|
|
||
| for (VkSubmitInfo& submit_info : submit_infos) | ||
| { | ||
| if (!previous_submit_signal_semaphores.empty()) |
There was a problem hiding this comment.
Ouch. This is still incomplete. If submit i has no signal semaphores, then submit i+1 has no dependency object to wait on, so serialization stops there. The current code only propagates existing signals forward. Need fix.
There was a problem hiding this comment.
the fix would be to create (+own somewhere) additional glue-semaphores?
| // Original waits stripped from each submit before injection. | ||
| std::vector<VulkanSubmitSemaphores> original_wait_semaphores_; | ||
| /// Original waits stripped from each submit before injection, keyed by either `VkSubmitInfo*` or `VkSubmitInfo2*`. | ||
| std::unordered_map<void*, VulkanSubmitSemaphores> original_wait_semaphores_; |
There was a problem hiding this comment.
the void* as key raised the question about lifetime of pointees:
- this looks like it's pointing into DecodeAllocator memory, valid only for this block before the allocator reuses it.
VulkanSubmitJobExecutoronly ever lives on the stack, so the validity of acquired VkSubmitInfo(2) pointers seems guaranteed here.
so, my verdict is this should be safe with the current usage pattern.
it 'would' be problematic when VulkanSubmitJobExecutor had a persistent lifetime.
roughly correct? does this line up with what you have in mind?
There was a problem hiding this comment.
yes, you even mention it in the doc:
"It (VulkanSubmitJobExecutor) must outlive the queue submit that consumes those structs."
There was a problem hiding this comment.
Reworked a bit: now the "execution" use used within the scope of the queue-submit, and the "executor" is a per-device object which keeps track of semaphores created on the fly to force synchronisation.
antonio-lunarg
force-pushed
the
antonio-serialize-submissions
branch
from
b5d10b2 to
08b8064
Compare
Add a new replay option that serializes queue submissions by inserting semaphores so each submit waits for the previous, preventing concurrent execution of multiple submissions during replay. Implement serialization in VulkanSubmitJobExecutor with SerializeExecution overloads for VkSubmitInfo and VkSubmitInfo2, and call SerializeExecution from OverrideQueueSubmit/OverrideQueueSubmit2 when the option is set. Wire the option through CLI parsers, replay_settings, and help text, and update desktop/android usage docs. Refactor submit executor storage to map submit pointers to semaphore storage to avoid multiple injections.
Ensure that when `--serialize-queue-submissions` is used, consecutive submits within a single `vkQueueSubmit()` / `vkQueueSubmit2()` call are reliably serialized even if some submits do not originally signal any semaphores.
antonio-lunarg
force-pushed
the
antonio-serialize-submissions
branch
from
3c428af to
76b08a2
Compare
2 participants
Add a new replay option that serializes queue submissions by inserting semaphores so each submit waits for the previous, preventing concurrent execution of multiple submissions during replay.
Implement serialization in
VulkanSubmitJobExecutorwithSerializeoverloads forVkSubmitInfoandVkSubmitInfo2, and callSerializefromOverrideQueueSubmit/OverrideQueueSubmit2when the option is set.Wire the option through CLI parsers, replay_settings, and help text, and update desktop/android usage docs. Refactor submit executor storage to map submit pointers to semaphore storage to avoid multiple injections.