vulkan/wsi: Report the correct min/maxImageCount
authorJason Ekstrand <jason.ekstrand@intel.com>
Fri, 4 Nov 2016 22:42:48 +0000 (15:42 -0700)
committerJason Ekstrand <jason.ekstrand@intel.com>
Fri, 11 Nov 2016 06:40:51 +0000 (22:40 -0800)
commit4fa0ca80eeeac813affcbb0129ed61f1534d8df0
tree9db55ef7bea272e48b6ad6b178dcc0b5684a12d9
parent932bb3f0ddf22a9cbdf6d45089547765027b4397
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>
src/vulkan/wsi/wsi_common_wayland.c
src/vulkan/wsi/wsi_common_x11.c