summaryrefslogtreecommitdiffstats
path: root/src/mesa
diff options
context:
space:
mode:
authorJason Ekstrand <[email protected]>2016-11-04 15:42:48 -0700
committerEmil Velikov <[email protected]>2016-11-23 18:49:50 +0000
commitcf8b11fc6ce5618117bb48aca108ea448438a926 (patch)
treeb40515a4896b113e9859691d0de1bc3c6477c3fe /src/mesa
parent6520a64c4dadf03e2991a997c2399e3cc181b5c2 (diff)
vulkan/wsi: Report the correct min/maxImageCount
From the Vulkan spec 1.0.32 section 29.6 docs for vkAcquireNextImageKHR: "Let n be the total number of images in the swapchain, m be the value of VkSurfaceCapabilitiesKHR::minImageCount, and a be the number of presentable images that the application has currently acquired (i.e. images acquired with vkAcquireNextImageKHR, but not yet presented with vkQueuePresentKHR). vkAcquireNextImageKHR can always succeed if a ≤ n - m at the time vkAcquireNextImageKHR is called. vkAcquireNextImageKHR should not be called if a > n - m with a timeout of UINT64_MAX; in such a case, vkAcquireNextImageKHR may block indefinitely." With minImageCount == 2 (as it was previously, the client is allowed to acquire all but one image withoutblocking. If we really need 4 images for mailbox mode + pageflipping, then we need to request a minimum of 4 images up-front. This is a bit unfortunate because it means we will always consume 4 images. In the future, we may be able to optimize this a bit by waiting until the server starts to flip and returning OUT_OF_DATE to get the client to re-allocate with more images or something like that. Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Dave Airlie <[email protected]> Cc: "13.0" <[email protected]> (cherry picked from commit 4fa0ca80eeeac813affcbb0129ed61f1534d8df0)
Diffstat (limited to 'src/mesa')
0 files changed, 0 insertions, 0 deletions