On Fri Jun 30 06:23:39 2023 +0000, Giovanni Mascellani wrote:
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.
So in isolation I think the solution proposed by this patch set is fine, and even looks prettiest. *But* what I remember from that discussion—and Henri will undoubtedly be able to express this more eloquently—is that the concern is
(a) we might want to do something more complicated than just vkQueuePresent()—cf. the issues about fullscreen window styles / presenting to the client rect. I'm not sure but this might also turn out to be an issue for DirectComposition.
(b) we might want to plumb presentation through D3DKMTPresent() [which may be necessary to achieve the above], and it will probably not be possible to do any vkd3d calls from the Unix side.