Aug. 28, 2023
4:19 a.m.
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. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/292#note_43536