summaryrefslogtreecommitdiff
path: root/configure.ac
diff options
context:
space:
mode:
authorJason Ekstrand <jason.ekstrand@intel.com>2016-11-04 15:42:48 -0700
committerJason Ekstrand <jason.ekstrand@intel.com>2016-11-10 22:40:51 -0800
commit4fa0ca80eeeac813affcbb0129ed61f1534d8df0 (patch)
tree9db55ef7bea272e48b6ad6b178dcc0b5684a12d9 /configure.ac
parent932bb3f0ddf22a9cbdf6d45089547765027b4397 (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 <jason@jlekstrand.net> Reviewed-by: Dave Airlie <airlied@redhat.com> Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Diffstat (limited to 'configure.ac')
0 files changed, 0 insertions, 0 deletions