In what situations is VkFence better than vkQueueWaitIdle for vkQueueSubmit?

Question

As described here vkQueueWaitIdle is equivalent of vkFence. So in which situation to use either of them.

Answer 1

As you say, vkQueueWaitIdle() is just a special case of Fence use.

So you would use it when you would have to write 10 lines of equivalent Fence code instead — especially if you do not care to remember all the previous queue submissions. It is somewhat a debug feature (most frequently you would use it temporarily to test your synchronization). And it may be useful during cleanup (e.g. application termination, or rebuilding the swapchain).

In all other cases you should prefer VkFences, which are more general:

1. You can take advantage of advanced vkWaitForFences() usage. I.e. wait-one vs wait-all and timeout.

2. You supply it to some command that is supposed to signal it (can't do that with vkQueueWaitIdle()). You can do something like:
   vkQueueSubmit( q, 1, si1, fence1 );
vkQueueSubmit( q, 1, si2, fence2 );
vkWaitFences( fence1 ); // won't block on the 2nd submit unlike vkQueueWaitIdle(q)
   which can even be potentially faster than:
   vkQueueSubmit( q, 1, si1, 0 );
vkQueueWaitIdle(q);
vkQueueSubmit( q, 1, si2, 0 );

3. You can just query the state of the Fence without waiting with vkGetFenceStatus(). E.g. having some background job and just periodically asking if it's done already while you do other jobs.

4. VkFence may be faster even in identical situations. vkQueueWaitIdle() might be implemented as vkQueueSubmit( q, 0, nullptr, fence ); vkWaitFences( fence, infiniteWait ); where you would potentially pay extra for the vkQueueSubmit.