Jason Ekstrand 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 acq
On Sun, Oct 1, 2017 at 10:32 PM, Neil Roberts wrote:
> Jason Ekstrand 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
Jason Ekstrand 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
Hey, Neil!
On October 1, 2017 3:12:46 PM Neil Roberts wrote:
Jason Ekstrand writes:
+ /* For true mailbox mode, we need at least 4 images:
+* 1) One to scan out from
+* 2) One to have queued for scan-out
+* 3) One to be currently held by the Wayland compositor
+* 4) On
Jason Ekstrand writes:
> + /* For true mailbox mode, we need at least 4 images:
> +* 1) One to scan out from
> +* 2) One to have queued for scan-out
> +* 3) One to be currently held by the Wayland compositor
> +* 4) One to render to
> +*/
> caps->minImageCount = 2;
>
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
