<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 1, 2017 at 10:32 PM, Neil Roberts <span dir="ltr"><<a href="mailto:bpeeluk@yahoo.co.uk" target="_blank">bpeeluk@yahoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> writes:<br>
<br>
> Hey, Neil!<br>
<br>
Hey Jason :)<br>
<span class="gmail-"><br>
> Yeah... That's a bit unfortunate.  The problem is that we have no way of<br>
> returning a different number of images depending on the mode.  In theory,<br>
> we could start out at 2 and return SUBOPTIMAL and force the application to<br>
> recreate the swapchain with more images until we have enough.  That would<br>
> be a real pain though...  In not sure what the best option is.<br>
<br>
</span>Hm, was there a problem with the previous approach? Ie, in the surface<br>
caps it always returns minImages as two but when it comes to creating<br>
the swapchain if the present mode is MAILBOX then it will go ahead and<br>
create 4 images. The parameter in the create call is also called<br>
“minImages” not “numImages” and the spec implies it’s ok to create more<br>
than were requested. It seems like that would just do the right thing.<br>
</blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">I wish...  Unfortunately, the spec says:</div><div class="gmail_extra"><br></div><div class="gmail_extra">Let <em>n</em> be the total number of images in the swapchain, <em>m</em> be the value of
<code>VkSurfaceCapabilitiesKHR</code>::<code>minImageCount</code>, and <em>a</em> be the number
of presentable images that the application has currently acquired (i.e.
images acquired with <code>vkAcquireNextImageKHR</code>, but not yet presented with
<code>vkQueuePresentKHR</code>).
<code>vkAcquireNextImageKHR</code> <strong class="gmail-purple">can</strong> always succeed if <span class="eq">a ≤ n - m</span> at
the time <code>vkAcquireNextImageKHR</code> is called.
<code>vkAcquireNextImageKHR</code> <strong class="gmail-purple">should</strong> not be called if <span class="eq">a > n - m</span> with a
<code>timeout</code> of <code>UINT64_MAX</code>; in such a case,
<code>vkAcquireNextImageKHR</code> <strong class="gmail-purple">may</strong> block indefinitely.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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. :-(</div><div class="gmail_extra"><br></div><div class="gmail_extra">--Jason<br></div></div>