You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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;Possibly related: