Vulkan Swapchain and Submit Synchronization Incorrect

[cwfitzgerald]

We are currently using a single ping-pong semaphore (I'm calling this set of two semaphores a "relay semaphore") for all of our synchronization between acquire/present and between submissions. This is wrong for multiple reasons.

First using the same relay semaphore for both the submit -> present barrier and the submit -> submit barrier means that a single semaphore is being waited on twice. The act of waiting on a semaphore also resets the semaphore, so waiting on a single semaphore twice results in undefined behavior.

Second we are using the same relay semaphore for all acquire -> submit -> present cycles. This would be fine if we could guarantee that the previously used submit had finished its wait and the semaphore was reset by the time we scheduled the following acquire, but we can't. We need to have N relay semaphores, one per acquire cycle, until we can prove that the least-recently-used semaphore is finished being used.

I have provided the diagram of how submission synchronization needs to work with lines. Blue lines are swapchain relay semaphores (one set per frame). Orange lines are submit -> submit relay semaphore (a single one on the device.

flowchart LR
    A1[Acquire 1] --> S1[Submit 1]
    S1 --> P1[Present 1]
    S1 --> S21

    A2[Acquire 2] --> S21[Submit 2]
    S21 --> S22[Submit 3]
    S22 --> P2[Present 2]
    S22 --> S3[Submit 4]
    S3 --> S4
    
    A3[Acquire 3] --> S4[Submit 5]
    S4 --> P3[Present 3]

    subgraph Frame 3
        A3
        S4
        P3
    end

    subgraph Free Submission
        S3
    end

    subgraph Frame 2
        A2
        S21
        S22
        P2
    end

    subgraph Frame 1
        A1
        S1
        P1
    end

    linkStyle 2,4,6,7 stroke:#ffa600,whoops;
    linkStyle 0,1,3,5,8,9 stroke:#019297,whoops;

Loading

Possibly related:

• On Nvidia 535, tearing/flickering observed with PresentMode::Fifo #5491
• Window resizing lags with white rectangles on Windows #5374
• Vulkan sometimes present while unfinished #4919
• Screen flickering on Nvidia Optimus #3452

[jimblandy]

The use of relaxed atomics in there seems very strange to me. I can't imagine how one could get away with not caring about which values concurrent threads would see for relay_index.

We need to have N relay semaphores, one per acquire cycle, until we can prove that the least-recently-used semaphore is finished being used.

This sounds like something akin to wgpu_hal::vulkan::Fence::FencePool. In fact, perhaps we could literally just replace Queue::relay_semaphores and relax_index with a vulkan::Fence?? Since vkQueueSubmit2 can specify the semaphore value to wait for, a single timeline semaphore should be sufficient for all submit-submit synchronization.

[cwfitzgerald]

So I thought about that, and you can wait and signal the same timeline semaphore, but we can't assume timeline semaphores exist, so we'd need a binary semaphore fallback anyway.

[jimblandy]

So I thought about that, and you can wait and signal the same timeline semaphore, but we can't assume timeline semaphores exist, so we'd need a binary semaphore fallback anyway.

Right - my point being, vulkan::Fence is exactly a timeline semaphore with a vkFence collection as a fallback. I added some doc comments to vulkan:: Fence about this just recently.

[cwfitzgerald]

We need a timeline semaphore with a vk::Semaphore fallback, so I'm not sure we can share the infra.