I have code that looks like this:

vkQueueSubmit(queue, 1, &infoB, fenceB); // ~130 ms to complete

while(1) {
    vkWaitForFences(device, 1, &fenceA, true, UINT64_MAX);
    vkResetFences(device, 1, &fenceA);

    if (vkGetFenceStatus(device, fenceB) == VK_SUCCESS) {
        vkResetFences(device, 1, &fenceB);
        // do stuff
    }

    vkQueueSubmit(queue, 1, &infoA, fenceA); // ~1 ms to complete
}

and for some reason, after fenceA is reset, on the next iteration it waits for work submitted outside the loop.

What is going on here ?

I have code that looks like this:

vkQueueSubmit(queue, 1, &infoB, fenceB); // ~130 ms to complete

while(1) {
    vkWaitForFences(device, 1, &fenceA, true, UINT64_MAX);
    vkResetFences(device, 1, &fenceA);

    if (vkGetFenceStatus(device, fenceB) == VK_SUCCESS) {
        vkResetFences(device, 1, &fenceB);
        // do stuff
    }

    vkQueueSubmit(queue, 1, &infoA, fenceA); // ~1 ms to complete
}

and for some reason, after fenceA is reset, on the next iteration it waits for work submitted outside the loop.

What is going on here ?

• synchronization
• vulkan

1 Answer 1

You are submitting to a single queue. Pipeline stages can overlap, but issue to the head of the pipe is likely to be ~serial even if you have no barriers.

At the end of the first iteration your queue looks like:

Work for info B
Signal fence B for info B
Work for info A
Signal fence B for info A

Your first iteration skips over waiting for Fence B, but the second iteration will wait for Fence A and the work for Info A is probably stuck in the queue waiting for the Info B submit to complete first.

If you want things to progress in parallel to slow work, you'll need to use two queues, but even there you may find you get stalls depending on how many queues the hardware can actually run in parallel.