Understanding Vulkan concepts: swapchain, framebuffer

Question

VkInstance is an instance of a program

VkPhysicalDevice represents a physical device. So if I have an Intel HD Graphics and a GTX 1660 there will be one VkPhysicalDevice for each

QueueFamily, for now, will be a queue that helps in sending and receiving things from the GPU. There are many queues, like one for transfering data from memory, other that processes computation commands, etc.

A VkDevice is a VkPhysicalDevice associated with a queue family. It makes sense that we can have multiple VkDevices for the same VkPhysicalDevice. We may use a GPU for lots of things simultaneously like decode video and render a 3D scene. I guess that's what it's for.

We need a VkSurfaceKHR to display things, because Vulkan is device agnostic, so it makes sense that we need to pass a window to it.

Now comes the concept of SwapChain. I can't differentiate it from a Queue (from a QueueFamily). Wasn't the Queue the structure to send and receive images from the GPU? Why not simply use a Queue to present images on the VkSurfaceKHR?

There's also the concept of framebuffers. For me a framebuffer would be the rendered image that is displayed on screen, so it'd be an image of the SwapChain.

Answer 1

VkInstance is an instance of a program

No, it is an instance of the Vulkan execution system. You could have multiple Vulkan instances (though there's not much point).

A VkDevice is a VkPhysicalDevice associated with a queue family.

No, it's not. VkPhysicalDevice represents a GPU (to oversimplify things). VkDevice is an interface to a GPU. If VkPhysicalDevice is a class, VkDevice is an instance of that class.

VkDevice creation requires that you specify which queue families (note the plural) you want to use and how many queues from each family should be made available.

Now comes the concept of SwapChain. I can't differentiate it from a Queue (from a QueueFamily).

Swapchains basically have nothing to do with queues specifically. They sometimes use queues, but they're not really related to a queue.

Wasn't the Queue the structure to send and receive images from the GPU?

A queue is a means of sending work to the GPU for it to execute. That work could be transferring data to/from GPU-accessible memory.

Why not simply use a Queue to present images on the VkSurfaceKHR?

That is how it works. vkQueuePresentKHR, as the name suggests, is a queue operation. It presents the given swapchain image on the given queue.

What isn't allowed is the ability to present arbitrary images. Images in a swapchain don't belong to you (or to Vulkan); they belong to the OS. You can ask to use one of them, and that request will hopefully be granted. You can present it once rendered. But you never own it.

This inflexibility for the user exists to allow maximum flexibility for OS's and implementations of Vulkan. Vulkan needs to run on a wide variety of hardware and operating systems with their own special ways of handling display logic. So abstracting all of those differences away requires being inflexible in some regards.

Answer 2

Swapchain is an abstraction for dealing with platform-specific quirks. Think of it as a wrapper for GDI+, DXGI, X11, or Wayland, and their calls, limits, and quirks.

Additionally, swapchain is more than a "normal" queue executed stuff. It has present modes and whatnot. Its semantics is also a bit different. Its purpose is to hand over data to a Presentation Engine, which is typically an external thing to Vulkan that has to be dealt with.

Framebuffer in the Vulkan has the meaning of all the (historically opaque) buffers needed for a frame. Over time, many think this means color buffers, as those are the one most talked about that always needed special treatment via swap chains. But it is also depth buffers and stencil buffers. And Vulkan also newly has input buffers.

Imageless Framebuffer was also added in extension and added to Vulkan 1.2. With that it is better to think of it as "VkFramebufferMetadata". In this case vkCreateFramebuffer just imbues the Render Pass with meta-data (creation parameters) of the Images that will be used in the framebuffer role. This way vkCreateFramebuffer gives the driver an off-the-hot-path opportunity to compute an overall strategy of how it will work with the framebuffer, while allowing to provide the actual images later.