[Mesa-dev] [PATCH v2 2/3] vulkan/wsi: Report the correct min/maxImageCount

[Jason Ekstrand]

On Sun, Oct 1, 2017 at 10:32 PM, Neil Roberts <bpeeluk at yahoo.co.uk> wrote:

> Jason Ekstrand <jason at jlekstrand.net> writes:
>
> > Hey, Neil!
>
> Hey Jason :)
>
> > Yeah... That's a bit unfortunate.  The problem is that we have no way of
> > returning a different number of images depending on the mode.  In theory,
> > we could start out at 2 and return SUBOPTIMAL and force the application
> to
> > recreate the swapchain with more images until we have enough.  That would
> > be a real pain though...  In not sure what the best option is.
>
> Hm, was there a problem with the previous approach? Ie, in the surface
> caps it always returns minImages as two but when it comes to creating
> the swapchain if the present mode is MAILBOX then it will go ahead and
> create 4 images. The parameter in the create call is also called
> “minImages” not “numImages” and the spec implies it’s ok to create more
> than were requested. It seems like that would just do the right thing.
>

I wish...  Unfortunately, the spec says:

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.

Because this is based on the number of images in the swapchain and the
VkSurfaceCapabilitiesKHR field, if we return a swapchain with more images,
n will be larger but not m so that just means that they can acquire more
images, not that we've reserved more.  Arguably, that's a spec bug and I'll
file one and see where it goes.  However, it's definitely what the spec
says today. :-(

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20171002/eb9f575e/attachment.html>