What I understand is that if we set the member variable minImageCount of VkSwapchainCreateInfoKHR to some value, say n, then the actual number of images created in the swapchain may be > n.
I guess the logic of this must be that the application can do with n but would be happier with more. But what sort of situation would this be? E.g., if triple buffering I want presentation mode VK_PRESENT_MODE_MAILBOX_KHR and 3 images, no more no less (more would not help).
Incidentally, I have done some experiments creating swapchains with various presentation modes and minImageCount. In all cases, the number of images created was exactly minImageCount.
Appreciate your insight into this matter.
[QUOTE=theDancer;42399]What I understand is that if we set the member variable minImageCount of VkSwapchainCreateInfoKHR to some value, say n, then the actual number of images created in the swapchain may be > n.
I guess the logic of this must be that the application can do with n but would be happier with more.[/quote]
No, the logic of that is “the implementation may force more on you.”
Let’s say you ask for 2 images, but there is some driver switch that allows users to force triple buffering. The implementation would be able to make your application accept having 3 images.
[QUOTE=Alfonse Reinheart;42400]No, the logic of that is “the implementation may force more on you.”
Let’s say you ask for 2 images, but there is some driver switch that allows users to force triple buffering. The implementation would be able to make your application accept having 3 images.[/QUOTE]
Triple buffering happens when the VkSwapchainCreateInfoKHR member variable presentMode is VK_PRESENT_MODE_MAILBOX_KHR and no. of images >= 3. Moreover, VK_PRESENT_MODE_MAILBOX_KHR with no. of images = 2 doesn’t even make sense as there’s no next image to draw after the current one is complete.
So, I see your point about the implementation forcing triple buffering if the programmer has VK_PRESENT_MODE_MAILBOX_KHR but was careless enough to ask only 2 images. However, other than this situation the implementation can’t “force” triple buffering, e.g., if presentMode is not set to VK_PRESENT_MODE_MAILBOX_KHR in the program.
Ok, here’s an alternate explanation for why the system might create more images in the swapchain than the min asked for: both present modes VK_PRESENT_MODE_FIFO_KHR and VK_PRESENT_MODE_FIFO_RELAXED_KHR put newly drawn frames to the back of the queue of swapchain images while the display takes images from the front of the queue; moreover, the program has to wait if the queue is full. Therefore, in this case the longer the size of the queue the less frequently the program blocks on a full queue. So, with these two present modes it is advantageous for the system to grant more images than the min asked for.