What exactly are framebuffers and swapchains?

Question

So I'm a bit confused with the concept of framebuffers. I've done my research but I always find different definitions, often these two:

• A framebuffer is an array of multiple different images. But this definition, or at least to me, sounds more like what a swapchain is: a series of framebuffers.

• A framebuffer is an array of pixels forming a single image, so kind of like a bitmap (but from what I've read, it can contain more information than just the color, like depth values and stuff), and when that bitmap is filled by the pipeline, it is queued for presentation. This would make much more sense to me, because then the swapchain also makes sense: a collection of framebuffers, so there can be one that is used as a rendering target, and another one for presentation, in the case of double buffering, and the swapchain handles swaping them with the correct timing to improve framerate stabilization.

Which of these is correct? Because I'm tired of hearing different things every time I look for a bit of information.

Please keep in mind that I'm learning Vulkan with no graphics expirience at all (I know it's not recommended) so I'm much more interested in the concepts than the code right now.

Answer 1

I was where you are now, not too long ago, so maybe I can explain it from the perspective of a noob.

When you are preparing to render a frame on the GPU using Vulkan, you'll need to perform those drawing operations into some chunk of memory on the GPU. Those memory chunks are called images. To render things on the GPU, you use Shader programs. Those shader programs need to know into which memory chunk they will draw -- in other words, into which image. A shader can draw to more than one image. In the fragment shader, it would be something like:

layout(location 0) out vec4 imgA;
layout(location 1) out vec4 imgB;

vec4, in this case, is the amount of channels each pixel of the image has (RGBA, for example). Thus, you woud write 4 components to each pixel. Each location means a different image.

So, each (fragment) shader can write to 1 or more images. BUT also, shaders can READ from images passed to them. This is usuful to build images as series of steps, which you then composite together later on. Imagine something like Adobe Photoshop image, which is made up of a series of layers. Different Passes/Renderpasses/Subpasses kindof represent a new layer or effect. If the fragment shader writes to 1 output image, then that's like 1 new layer. If it writes to 2 output images, then it's like 2 layers for that shader, and so on. Those images can be be passed as inputs to subsequent shaders within the same frame. At some final step in the frame building process, you grab all those previously made images and combine them into a final image, and (usually) display it to the screen by writing it to a swapchain image.

So, a VkFramebuffer is a structure, similar to a list, for us to organize the set of images that we will provide to the shaders for their drawing operations. Some of those images will be used as inputs, others as outputs, etc.

When you create a VkRenderpass object, you tell it that there will be X amount of input images, color images, depth images, etc. But you don't tell it which actual images to use (as in, the actual RAM to use for those images). The VkFramebuffer is where you bind the actual images (Memory/RAM) to the VkRenderpass.

So, VkFramebuffer is a way to bind actual images to the placeholders in the VkRenderpass.

A swapchain is a premade series of memory chunks (images) on the GPU. It has special qualities that writing to it is like writing directly to the Window surface (kind of). Because they are just images (albeit, with special requirements), they can be bound to VkFramebuffers, and thus written to by shaders.

Answer 2

In Vulkan parlance, a VkFramebuffer is a container that references images which can be used as the attachments in a render pass instance. Render pass attachments are the destination for rendering operations. So if you want to render to a specific image, at some point, you'll need to shove it into a VkFramebuffer and invoke vkCmdBeginRenderPass.

A swapchain has nothing to do with a framebuffer (technically). A swapchain is a series of images which you do not own. You can ask the display engine to borrow one of the images for a period of time, during which you may render to it or whatever other operations the swapchain allows you to do with its images. After some time, you can tell the display engine to show the image you have used to a particular display, after which point you can't use that swapchain image until you borrow it again.

So while they both have "a series of images", they are in no way alike. Framebuffers render to all of their images during a rendering operation (in accord with the render pass's subpass attachment usages). You're not expected to borrow all of a swapchain's images at the same time. You only borrow them one at a time (one per display surface).

Now, since a swapchain image can only be used in ways that the display engine allows, and the only way the display engine is required to allow you to use it is as a color attachment, if you actually want to see the results in a display device (which Vulkan doesn't require), an image from a swapchain is going to end up in a VkFramebuffer at some point.

Answer 3

It is bit of a problem how it historically evolved.

Historically, frame buffer is everything for a frame, and it was largely opaque. That includes color buffer(s), depth buffer(, and newly in Vulkan: an input buffer).

Also historically there was not that much preprocessing and compute, and things were tied to a screen. Hence the association with swapchain. But Vulkan can easily be headless, so that does not make sense.

So sometimes "framebuffer" is used interchangably for "color buffer swapchain images". But generally (and specifically the Vulkan object) means "buffers for frame that need special consideration"; not only color buffer, and irrespctive if they end up on screen or not.