On Fri Jun 30 06:23:40 2023 +0000, Zebediah Figura wrote:
I'm a bit fuzzy on the details, but wasn't there an idea to use event-based synchronization *with* a worker thread? Something like, dxgi spawns a worker thread which waits (on a GPU-signaled fence?) for the queue to be safe to directly call vkQueuePresent()?
I don't specifically remember discussing this, but it is certainly an option. BTW, are you proposing it because you think it would be better than the current proposal, or just as something worth considering?
So there would be an `ID3D12Fence` object, `Present()` would push a signal operation and `SetEventOnCompletion()` to it on the command queue and the worker thread would wait for that event and then acquire the `VkQueue` and enqueue the commands it needs.
The part that doesn't thrill me is the fact that DXGI still directly accesses the `VkQueue` object, which I tend to see as an internal implementation detail to vkd3d. On the other hand it's nice that we don't need new API from vkd3d (even if, in the future, we were to need something other than `vkQueueSubmit()` and `vkQueuePresentKHR()`).
Hopefully implementing this idea shouldn't require too much work, it should share a good amoung of code with my current proposal. I'll try.