On Mon Aug 28 09:19:20 2023 +0000, Henri Verbeet wrote:
I think the fence worker is unsuitable. If it has some fences to wait
for, it must poll `vkWaitSemaphoresKHR()` with a zero or extremely short wait time in case some descriptor writes come along. To avoid spinning we would need to use a short wait time, not zero, which will delay descriptor handling. And when writes do occur, they may delay fence handling. Well, it depends on the specifics, I think. In particular:
- How long does a d3d12_desc_flush_vk_heap_updates_locked() call
typically take? How long does it maximally take? If the answer to the previous question is some approximation of "infinity", could we put a lower bound on that by e.g. limiting the maximum number of descriptors we process in a single d3d12_desc_flush_vk_heap_updates_locked() call?
- How long does waiting for a fence typically take once we know it has
been submitted? Would it be terrible to poll fences with e.g. a 1ms timeout?
- What is the worst case behaviour? If descriptor writes were to get
stuck behind a fence we'd need to wait for d3d12_command_queue_ExecuteCommandLists() to process them, but that should be no worse than what we're currently doing. The reverse might be worse, but we should be able to avoid that by polling fences inside d3d12_desc_flush_vk_heap_updates_locked() if needed.
- Are there any nasty edge cases?
From the Vulkan spec:
timeout is the timeout period in units of nanoseconds. timeout is adjusted to the closest value allowed by the implementation-dependent timeout accuracy, which may be substantially longer than one nanosecond, and may be longer than the requested period.
The shortest timeout in current drivers is probably much shorter than we need, but this could bite us in the future, and there's no way to query the actual minimum value.