Chapter 5: swapchain
This chapter is being written currently
In the previous chapter, we learned how to do GPU-based rendering, although an important limitation remained: we were not able to do real-time rendering, where the renderer runs continuously and the results are streamed to the screen. Offline renderers have all sorts of cool applications, but as we will see, bridging the gap to real-time rendering is not too much of a hassle: the hard parts of the Vulkan API are behind us!
Nonetheless, we have to be careful no to underestimate this task. Naively, we may think that we could use a simple while loop, where we would run a draw operation, extract its result to CPU and call a system function to print it to the screen, however the performance would not be satisfactory. Indeed, extracting the results to the CPU and printing them to the screen takes time, and we could use this time for working on the next render instead of just waiting. Furthermore, we could skip moving data to the CPU entirely: clearly, when we are in fullscreen, the result of our rendering operation can be directly forwarded to the screen. Even when we are rendering in a windowed manner, we could expect that the system lets the display controller and the GPU communicate directly to update the portion of the screen to which the results of the render are mapped.
In this chapter, we will learn how to do pipelined rendering by juggling around multiple copies of rendering resources, and we will see how to rely on low-level extensions that implement this mechanism in a way that is optimized for your operating system.
A. A high-level overview
A.1. Window and surface
We will learn how to set the contents of windows to the result of a Vulkan rendering operation, but first, we need a window to print our results to. Windows are not managed by Vulkan. They are a system-side feature that need to be created from the CPU. As different systems handle windows in different ways, we use cross-platform libraries that let us manipulate windows in an abstracted way. One such library is GLFW, which supports Windows, macOS, Wayland and X11. In addition to abstracting away the implementation details of window handling, they also provide a cross-platform way of handling inputs. Alternatives include SFML and SDL, but GLFW is the most lightweight option.
In order to get GLFW to interact with Vulkan, In C, this would be #define GLFW_INCLUDE_VULKAN
Extension Surface VkSurfaceCapabilitiesKHR
A.2. Swapchain and presentation
Extension PresentFamily/queue swap extent format choice presentation modes vkCreateSwapchainKHR VkSwapchainCreateInfoKHR
A.3. Juggling resources
rendering loop vkGetSwapchainImagesKHR Framebuffers Image views, like before
A.4. Handling resizes
Resizes