1# Queue Present Wait Semaphore Management 2 3The following shorthand notations are used throughout this document: 4 5- PE: Presentation Engine 6- ANI: vkAcquireNextImageKHR 7- QS: vkQueueSubmit 8- QP: vkQueuePresentKHR 9- W: Wait 10- S: Signal 11- R: Render 12- P: Present 13- SN: Semaphore N 14- IN: Swapchain image N 15 16--- 17 18## Introduction 19 20Vulkan requires the application (ANGLE in this case) to acquire swapchain images and queue them for 21presentation, synchronizing GPU submissions with semaphores. A single frame looks like the 22following: 23 24 CPU: ANI ... QS ... QP 25 S:S1 W:S1 W:S2 26 S:S2 27 GPU: <------------ R -----------> 28 PE: <-------- P ------> 29 30That is, the GPU starts rendering after submission, and the presentation is started when rendering is 31finished. Note that Vulkan tries to abstract a large variety of PE architectures, some of which do 32not behave in a straight-forward manner. As such, ANGLE cannot know what the PE is exactly doing 33with the images or when the images are visible on the screen. The only signal out of the PE is 34received through the semaphore and fence that's used in ANI. 35 36The issue is that, in the above diagram, it's unclear when S2 can be destroyed or recycled. That 37happens when rendering (R) is finished and before present (P) starts. As a result, this time has to 38be inferred by a future operation. 39 40## Determining When a QP Semaphore is Waited On 41 42The ANI call takes a semaphore, that is signaled once the image is acquired. When that happens, it 43can be inferred that the previous presentation of the image is done, which in turn implies that its 44associated wait semaphore is no longer in use. 45 46Assuming both ANI calls below return the same index: 47 48 CPU: ANI ... QS ... QP ANI ... QS ... QP 49 S:S1 W:S1 W:S2 S:S3 W:S3 W:S4 50 S:S2 S:S4 51 GPU: <------ R ------> <------ R ------> 52 PE: <-- P --> <-- P --> 53 54The following holds: 55 56 S3 is signaled 57 => The PE has handed the image to the application 58 => The PE is no longer presenting the image (the first P operation is finished) 59 => The PE is done waiting on S2 60 61At this point, we can destroy or recycle S2. To implement this, a history of present operations is 62maintained, which includes the wait semaphore used with that presentation. Associated with each 63present operation, is a QueueSerial that is used to determine when that semaphore can be destroyed. 64This QueueSerial has execution dependency on the ANI semaphore (QS W:S3 in the above diagram). 65 66Since the QueueSerial is not actually known at present time (QP), the present operation is kept in 67history without an associated QueueSerial. Once same index is presented again, the QueueSerial of 68QS before QP is associated with the previous QP of that index. 69 70At each present call, the present history is inspected. Any present operation whose QueueSerial is 71finished is cleaned up. 72 73ANI fence cannot always be used instead of QueueSerial with dependency on ANI semaphore. This is 74because with Shared Present mode, the fence and semaphore are expected to be already signaled on the 75second and later ANI calls. 76 77## Swapchain recreation 78 79When recreating the swapchain, all images are eventually freed and new ones are created, possibly 80with a different count and present mode. For the old swapchain, we can no longer rely on a future 81ANI to know when a previous presentation's semaphore can be destroyed, as there won't be any more 82acquisitions from the old swapchain. Similarly, we cannot know when the old swapchain itself can be 83destroyed. 84 85ANGLE resolves this issue by deferring the destruction of the old swapchain and its remaining 86present semaphores to the time when the semaphore corresponding to the first present of the new 87swapchain can be destroyed. Because once the first present semaphore of the new swapchain can be 88destroyed, the first present operation of the new swapchain is done, which means the old swapchain 89is no longer being presented. 90 91Note that the swapchain may be recreated without a second acquire. This means that the swapchain 92could be recreated while there are pending old swapchains to be destroyed. The destruction of both 93old swapchains must now be deferred to when the first QP of the new swapchain has been processed. 94If an application resizes the window constantly and at a high rate, ANGLE would keep accumulating 95old swapchains and not free them until it stops. 96 97## VK_EXT_swapchain_maintenance1 98 99With the VK_EXT_swapchain_maintenance1, all the above is unnecessary. Each QP operation can have an 100associated fence, which can be used to know when the semaphore associated with it can be recycled. 101The old swapchains are destroyed when QP fences are signaled. 102