<p>There is nothing in Vulkan which guarantees or requires this. So even if it were a safe assumption <em>today</em> (if it were enforced by Windows in some way), all it would take would be one Windows update to break you.</p>

<p>It's best to work with what you're given, even if what you're given may be more than you would prefer.</p>

CC BY-SA 3.0
2018-02-01T17:01:01.330Z
I find it hard to believe that there's no explicit way to have double-buffering. Uh, bad news then. I liked when my arrays had a fixed size.
unknown
CC BY-SA 3.0
2018-02-01T17:09:17.603Z
@demanze: Vulkan exists to tell you how the hardware works and for you to interface with it. What you do with that information is up to you. If a hard FIFO implementation has a `maxImageCount` of 1, then you can create your own image to serve as a second buffer for a double-buffering system. Or you can just fail to have your application work, as hard FIFO with only 1 presentable image makes it pretty much impossible to present images on every vblank, no matter how fast you render.
Nicol Bolas
CC BY-SA 3.0
2018-02-01T17:10:50.243Z
@demanze: If you want 2 presentable images, and the implementation supports 2 presentable images, then you can ask for 2 presentable images. Now it might give you more than that, but it will never give you *less*.
Nicol Bolas
CC BY-SA 3.0
2018-02-01T17:16:29.903Z
No, I didn't mean that I was afraid there would be only 1. I'm actually scared one implementation could give me 3 or more. In my current prototype, I have an array of size 2 (for pointers to images/imageViews/framebuffers apart of the Swapchain). Now, I could put a maximum of 16 or 64 and keep a fixed sized array but I would rather have a way to have always 2 with the spec backing me up somewhere. :)
unknown
CC BY-SA 3.0
2018-02-01T16:43:15.797Z
2018-02-01T16:43:15.797Z
Nicol Bolas
<p>I'm working on an engine for Win32 exclusively. Can I safely assume that the flag VK_PRESENT_MODE_FIFO_KHR will always generate 2 and only 2 images for the swapchain? </p>

<vulkan>
Vulkan: Swapchain image count with VK_PRESENT_MODE_FIFO_KHR
unknown
# Vulkan: Swapchain image count with VK_PRESENT_MODE_FIFO_KHR

(Asked by: username_0 on 2018-02-01)

I'm working on an engine for Win32 exclusively. Can I safely assume that the flag VK\_PRESENT\_MODE\_FIFO\_KHR will always generate 2 and only 2 images for the swapchain?

**Tags:** vulkan


---

## 1 answers

### Answer by username_1 on 2018-02-01. Score: 1

There is nothing in Vulkan which guarantees or requires this. So even if it were a safe assumption *today* (if it were enforced by Windows in some way), all it would take would be one Windows update to break you.

It's best to work with what you're given, even if what you're given may be more than you would prefer.

> **Comments:**
> **username_0**: I find it hard to believe that there's no explicit way to have double-buffering. Uh, bad news then. I liked when my arrays had a fixed size.  
> **username_1**: @demanze: Vulkan exists to tell you how the hardware works and for you to interface with it. What you do with that information is up to you. If a hard FIFO implementation has a `maxImageCount` of 1, then you can create your own image to serve as a second buffer for a double-buffering system. Or you can just fail to have your application work, as hard FIFO with only 1 presentable image makes it pretty much impossible to present images on every vblank, no matter how fast you render.  
> **username_1**: @demanze: If you want 2 presentable images, and the implementation supports 2 presentable images, then you can ask for 2 presentable images. Now it might give you more than that, but it will never give you *less*.  
> **username_0**: No, I didn't mean that I was afraid there would be only 1. I'm actually scared one implementation could give me 3 or more. In my current prototype, I have an array of size 2 (for pointers to images/imageViews/framebuffers apart of the Swapchain). Now, I could put a maximum of 16 or 64 and keep a fixed sized array but I would rather have a way to have always 2 with the spec backing me up somewhere. :)  

---

