Hmm, which test? I guess we do a Wait(0) and expect that to be signaled immediately, whereas waiting for the GPU to be done isn't fast enough?
I think that's likely enough to not _actually_ break something, that having the temporary todo is fine. But it also calls to question whether Wait(0) is actually the right thing.
Okay, so what I didn't notice is that the test has an additional fence wait in it, so that wait does deadlock if you use ID3D12CommandQueue::Signal() rather than ID3D12Fence::Signal().
Or could we even just swap the order?
I doubt any real program is going to be broken by splitting that commit, but in both orders you have a check that temporarily regresses. Partly because I couldn't choose between the orders, partly because the changes are somehow related, partly because they're both quite little, I ended up merging them. At any rate, I split that commit in both ways, you tell me which one you prefer: https://gitlab.winehq.org/giomasce/wine/-/commits/dxgi4 and https://gitlab.winehq.org/giomasce/wine/-/commits/dxgi5 (they both contain the same commit at the beginning to restrict testing to the test that actually matters and skip all the mode changing mess).
I don't think I have a strong preference. I guess dxgi4?
Well, before that commit it is a random moment between when `Present()` is called and when the frame is actually presented. Which moment it is depends on factors that should be irrelevant, like how many other waits there are in the queue and how they interact to each other (i.e., when the internal vkd3d queue is flushed), potentially even for waits that happen after `Present()` is called.
That's a good point, probably having it be consistent, even if slightly off, is better than not.
If we want to emulate (4), I guess we'd want to do a CPU wait for a semaphore signaled by the present command we just queued.
I don't think the present command can signal anything (neither fences nor semaphores) on Vulkan. It is a one way command, with respect to timing. AFAICT once you've submitted something with `vkQueuePresentKHR()` the only way to know something about its timing is to use VK_KHR_present_wait (which is a can of worms on its own, since it requires a dedicated thread for doing that wait, but that's material for another MR). I think VK_KHR_present_wait was added precisely because of this `vkQueuePresentKHR()` deficiency.
Bah, I forgot that :-/