Jason Ekstrand <ja...@jlekstrand.net> writes: > 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. :-(
Fair enough. Thanks for the explanation. Regards, - Neil . _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
