Giovanni Mascellani (@giomasce) commented about dlls/dxgi/swapchain.c:
{ const struct dxgi_vk_funcs *vk_funcs = &swapchain->vk_funcs; VkDevice vk_device = swapchain->vk_device;
VkFence vk_fence = swapchain->vk_fence; VkResult vr;
swapchain->vk_image_index = INVALID_VK_IMAGE_INDEX;
if ((vr = vk_funcs->p_vkAcquireNextImageKHR(vk_device, swapchain->vk_swapchain, UINT64_MAX,
VK_NULL_HANDLE, vk_fence, &swapchain->vk_image_index)) < 0)
VK_NULL_HANDLE, VK_NULL_HANDLE, &swapchain->vk_image_index)) < 0)
I'm not sure where you're reading that if `timeout` is `UINT64_MAX` then `vkAcquireNextImageKHR()` blocks until the next image is acquired, but [the Vulkan specs explicitly forbids the semaphore and fence to be null at the same time](https://registry.khronos.org/vulkan/specs/1.3-extensions/html/chap34.html#VU...), so I don't think this is a good solution. It's probably true that we shouldn't wait on the fence, but rather use the semaphore to synchronize directly with `vkQueuePresentKHR()` (and leave the synchronization inside the GPU, without involving the CPU). My recalling of last year is that should be pretty doable now, but I didn't embark in actually doing it, so there might be some details I'm missing.
For context, my understanding of `vkAcquireNextImageKHR()` is that you have to wait both on the call itself and on the fence or semaphore that is provided. That's because calling the function directly will wait until the Vulkan implementation is able to tell which image you're going to use, but it doesn't guarantee that that image can be used at once. It might still be used for presenting an earlier frame. So you don't have to touch it until the fence or semaphore is signaled (which is the reason why at least one must be provided: otherwise you'll never know when you can use that image).