Swapchain clarifications

Hello guys,

recently I’ve started studying again and because I always wanted to program games, I’ve decided to choose Vulkan as the topic of my thesis to learn something about graphics etc. I went through the tutorials available and briefly read the spec and now I’m working on my own code. At the moment I’m trying to understand the swapchain creation and I’m stuck at the following things:

VkSwapchainCreateFlagsKHR flags: the current spec (1.1.98) defines several flags

  • VK_SWAPCHAIN_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR
  • VK_SWAPCHAIN_CREATE_PROTECTED_BIT_KHR

The spec discusses only the MUTABLE bit.
Regarding the first flag, I’ve no clue what that means. It appears to me like several physical devices can split the job and work on a single image, where each part of the image is dedicated to one device. But that’s just my guess, as the spec it to abstract for me in this case.
I went through the spec and the protected bit is related to some memory protection, but I’m missing the background, why is that, what’s the usage or requirement for such functionality? I was not able to find anything in the appendix.

uint32_t minImageCount and VK_PRESENT_MODE_FIFO_KHR:
The VkSurfaceCapabilitiesKHR structure holds minImageCount and maxImageCount.

The spec says:
minImageCount is the minimum number of images the specified device supports for a swapchain created for the surface, and will be at least one.

maxImageCount is the maximum number of images the specified device supports for a swapchain created for the surface, and will be either 0, or greater than or equal to minImageCount.

So the spec allows to have minImageCount = maxImageCount = 1. However the spec also guarantees to support the VK_PRESENT_MODE_FIFO_KHR, which requires for its functionality at least 2 images (double buffering) in the swapchain, right?

VkFormat imageFormat vs VkColorSpaceKHR imageColorSpace:
Different types/different names, but same thing?
I understand that we need to
specify the color space of the surface/display and color space of the images, so the driver can perform transformations from the image color space to the display color space.
So why are there two different naming conventions?
Ideally these “formats” should be the same, but from what I read it’s inconvenient to use sRGB for any computations (color addition/subtraction; non-linear operations), while for
presenting its the way how display works and presents the colors, right?
Another thing is the newly introduced option MUTABLE, which allows to have different format of the swapchain images and image views. I thought one would prefer to stick to one format instead of multiple formats.
One thing I can imagine is, that the surface supports only a limited format/color space pairs which is inconvenient for the use case, so this is another way how to work
with format you want. Em I right?

VkImageUsageFlags imageUsage:
For the swapchain the only meaningful flag is the VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT, isn’t it?

Thank you for your help,
Renegade

1 Like

VK_SWAPCHAIN_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR just means the swapchain images will be created with VK_IMAGE_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT. That relates to device groups only, and is not relevant to apps using only single GPU.

VK_SWAPCHAIN_CREATE_PROTECTED_BIT_KHR will create the swapchain images as protected (VK_IMAGE_CREATE_PROTECTED_BIT). That means they cannot be read by Host. This is for pirate protection – e.g. preventing the frame to be grabbed at SW level. In effect e.g. you will not be able to read the Image on host and save it to a file.

Wrong. The compositor may have it’s own canvas\backbuffer, and the Swapchain Images may only act as hand-over images. That means one would be sufficient.

E.g. read specification of X Present Extension. It may copy immediately, schedule a copy, or use the swapchain image directly.

[HR][/HR]

[HR][/HR]

Preference and reality are two different things.
If you can, stick to one format. If you cannot, Vulkan offers a way out without having to copy.

TRANSFER_DST or VK_IMAGE_USAGE_STORAGE_BIT can also be useful if supported. Read usage flags may also be useful sometimes, e.g. if you want to grab a screenshot before you present the image.

PS: I am not sure what is the scope of your work, but you are unnecessarily getting stuck on new and advanced features.
For newb what is relevant is Vulkan 1.0 + VK_KHR_swapchain + VK_KHR_surface + VK_KHR_*_surface + VK_EXT_debug_report```VK_EXT_debug_utils```. Everything else is just noise.

Hi krOoze,

thanks a lot for the clarification. I see you are from CZ, right? I wanted to post you a private message, however, this is not possible at least not for me. Do you think we can have a short private chat via email or skype or so?

Thanks,
Renegade

Probably new user protection. I would probably not notice a PM on vBulletin anyway…

Sure, we can chat.

Is there a way to share a personal contact? The system didn’t let me write down my email and as I want to discuss something personally and of topic, I don’t want to use this forum for it.

Edit:
Ok, the system allowed me to send an email to you.

I sent you an email through the system.
PM button also appeared now on your profile page so I guess having 3 posts enabled this feature for you.