Written by experts with decades of rendering experience, this cookbook equips you with practical, hands-on recipes to master modern 3D graphics development by using bindless Vulkan.
Focusing on Vulkan 1.3, this second edition starts by setting up your development environment, and quickly transitions to building a robust 3D rendering framework using self-contained recipes. Each recipe helps you incrementally enhance your codebase, integrating a variety of 3D rendering techniques and algorithms into a cohesive project. You’ll get to grips with core techniques, such as glTF 2.0 physically based rendering, image-based lighting, and GPU-driven rendering. The chapters help you grasp advanced topics, including glTF animations, screen-space rendering techniques, and optimization strategies. You’ll also learn how to use glTF 2.0 advanced PBR extensions and handle complex geometry data, ensuring your rendering engine is both powerful and performant. These new additions will enable you to create dynamic and realistic 3D graphics environments, fully utilizing Vulkan’s capabilities.
By the end of this 3D rendering book, you’ll have gained an improved understanding of best practices used in modern graphic APIs and be able to create fast and versatile 3D rendering frameworks.
*Email sign-up and proof of purchase required
A Vulkan pipeline is an implementation of an abstract graphics pipeline, which is a sequence of operations that transform vertices and rasterize the resulting image. Essentially, it’s like a single snapshot of a “frozen” OpenGL state. Vulkan pipelines are mostly immutable, meaning multiple Vulkan pipelines should be created to allow different data paths through the graphics pipeline. In this recipe, we will learn how to create a Vulkan pipeline suitable for rendering a colorful triangle and explore how low-level and verbose Vulkan can be wrapped into a simple, high-level interface.
Vulkan pipelines require Vulkan shader modules. Check the previous recipe Initializing Vulkan shader modules before going through this recipe.
How to do it...
Let’s dive into how to set up a Vulkan pipeline suitable for our triangle rendering application. Due to the verbosity of the Vulkan API, this recipe will be one of the longest. We will begin with the high-level code in our demo application, Chapter02/02_HelloTriangle, and work our way through to the internals of LightweightVK down to the Vulkan API. In the following chapters, we will explore more details, such as dynamic states, multisampling, vertex input, and more.
Let’s take a look at the initialization and the main loop of Chapter02/02_HelloTriangle.
First, we create a window and a Vulkan context as described in the previous recipes.
Next, we need to create a rendering pipeline. LightweightVK uses opaque handles to work with resources, so lvk::RenderPipelineHandle is an opaque handle that manages a collection of VkPipeline objects, and lvk::Holder is a RAII wrapper that automatically disposes of handles when they go out of scope. The method createRenderPipeline() takes a RenderPipelineDesc structure, which contains the data necessary to configure a rendering pipeline. For our first triangle demo, we aim to keep things as minimalistic as possible, so we simply set the vertex and fragment shaders, and define the format of a color attachment. This is the absolute minimum required to render something into a swapchain image.
Inside the main loop, we acquire a command buffer as described in the recipe Using Vulkan command buffers and issue some drawing commands.
while (!glfwWindowShouldClose(window)) {
glfwPollEvents();
glfwGetFramebufferSize(window, &width, &height);
if (!width || !height) continue;
lvk::ICommandBuffer& buf = ctx->acquireCommandBuffer();
The member function cmdBeginRendering() wraps Vulkan 1.3 dynamic rendering functionality, which enables rendering directly into Vulkan images without explicitly creating any render passes or framebuffer objects. It takes a description of a render pass lvk::RenderPass and a description of a framebuffer lvk::Framebuffer. We will explore it in more detail in subsequent chapters. Here, we use the current swapchain texture as the first color attachment and clear it to a white color before rendering using the attachment load operation LoadOp_Clear, which corresponds to VK_ATTACHMENT_LOAD_OP_CLEAR in Vulkan. The store operation is set to StoreOp_Store by default.
The render pipeline can be bound to the command buffer in one line. Then we can issue a drawing command cmdDraw(), which is a wrapper on top of vkCmdDraw(). You may have noticed that we did not use any index or vertex buffers at all. We will see why in a moment as we look into GLSL shaders. The command cmdEndRendering() corresponds to vkCmdEndRendering() from Vulkan 1.3.
As we do not provide any vertex input, the vertex shader has to generate vertex data for a triangle. We use the built-in GLSL variable gl_VertexIndex, which gets incremented automatically for every subsequent vertex, to return hardcoded values for positions and vertex colors.
The GLSL fragment shader is trivial and just outputs the interpolated fragment color.
#version 460layout (location=0) in vec3 color;
layout (location=0) out vec4 out_FragColor;
voidmain(){
out_FragColor = vec4(color, 1.0);
}
The application should render a colorful triangle as in the following picture.
Figure 2.2: Hello Triangle
We learned how to draw a triangle with Vulkan using LightweightVK. It is time to look under the hood and find out how this high-level render pipeline management interface is implemented via Vulkan.
How it works…
To get to the underlying Vulkan implementation, we have to peel a few layers one by one. When we want to create a graphics pipeline in our application, we call the member function IContext::createRenderPipeline() which is implemented in VulkanContext. This function takes in a structure lvk::RenderPipelineDesc which describes our rendering pipeline. Let’s take a closer look at it.
The structure contains a subset of information necessary to create a valid graphics VkPipeline object. It starts with the topology and vertex input descriptions, followed by shader modules for all supported shader stages. While LightweightVK supports mesh shaders, in this book, we will use only vertex, fragment, geometry, and tessellation shaders.
Specialization constants allow Vulkan shader modules to be specialized after their compilation, at the pipeline creation time. We will demonstrate how to use them in the next chapter.
The maximum number of color attachments is set to 8. We do not store the number of used attachments here. Instead, we use a short helper function to calculate how many attachments we actually have.
When we call VulkanContext::createRenderPipeline(), it performs sanity checks on RenderPipelineDesc and stores all the values in the RenderPipelineState struct. LightweightVK pipelines cannot be directly mapped one-to-one to VkPipeline objects because the actual VkPipeline objects have to be created lazily. For example, LightweightVK manages Vulkan descriptor set layouts automatically. Vulkan requires a descriptor set layout to be specified for a pipeline object. To address this, the data stored in RenderPipelineState is used to lazily create actual VkPipeline objects through the function VulkanContext::getVkPipeline(). Let’s take a look at how this mechanism works, with error checking and some minor details omitted for simplicity.
The RenderPipelineState structure contains some precached values to avoid reinitializing them every time a new Vulkan pipeline object is created. All shader modules must remain alive as long as any pipeline that uses them is still in use.
With all data structures in place, we are now ready to go through the implementation of VulkanContext::createRenderPipeline(). Most of the error checking code is skipped for the sake of brevity.
The constructor iterates over vertex input attributes, and precaches all necessary data into Vulkan structures for further use.
Iterate and cache vertex input bindings and attributes. Vertex buffer bindings are tracked in bufferAlreadyBound. Everything else is a very trivial conversion code from our high-level data structures to Vulkan.
If specialization constants data is provided, copy it out of RenderPipelineDesc into local memory storage owned by the pipeline. This simplifies RenderPipelineDesc management on the application side, allowing it to be destroyed after the pipeline is created.
Now we can create actual Vulkan pipelines. Well, almost. A couple of very long code snippets await us. These are the longest functions in the entire book, but we have to go through them at least once. Though, error checking is skipped to simplify things a bit.
The getVkPipeline() functions retrieves a RenderPipelineState struct from a pool using a provided pipeline handle.
Then we check if the descriptor set layout used to create a pipeline layout for this VkPipeline object has changed. Our implementation uses Vulkan descriptor indexing to manage all textures in a large descriptor set and creates a descriptor set layout to store them. When new textures are created, there might not be enough space to store them, requiring the creation of a new descriptor set layout. Every time this happens, we have to delete the old VkPipeline and VkPipelineLayout objects and create new ones.
If there is already a valid Vulkan graphics pipeline compatible with the current descriptor set layout, we can simply return it.
if (rps->pipeline_ != VK_NULL_HANDLE) {
return rps->pipeline_;
}
Let’s prepare to build a new Vulkan pipeline object. We need to create color blend attachments only for active color attachments. Helper functions, such as formatToVkFormat(), convert LightweightVK enumerations to Vulkan.
Retrieve VkShaderModule objects from the pool using opaque handles. We will discuss how pools work in the next chapters. Here all we have to know is that they allow fast conversion of an integer handle into the actual data associated with it. The geometry shader is optional. We skip all other shaders here for the sake of brevity.
Create a suitable VkPipelineLayout object for this pipeline. Use the current descriptor set layout stored in VulkanContext. Here one descriptor set layout vkDSL_ is duplicated multiple times to create a pipeline layout. This is necessary to ensure compatibility with MoltenVK which does not allow aliasing of different descriptor types. Push constant sizes are retrieved from precompiled shader modules as was described in the previous recipe Initializing Vulkan shader modules.
As we peel more and more implementation layers, here is yet another level to peel. However, it is the last one. For convenience, the creation of actual VkPipeline objects is encapsulated in VulkanPipelineBuilder, which provides reasonable default values for all the numerous Vulkan data members that we do not want to set. Those familiar with Java will recognize a typical Builder design pattern here.
Finally, we call the VulkanPipelineBuilder::build() method, which creates a VkPipeline object and we can store it in our RenderPipelineState structure together with the pipeline layout.
The last method we want to explore here is VulkanPipelineBuilder::build() which is pure Vulkan. Let’s take a look at it to conclude the pipeline creation process.
First, we put provided dynamic states into VkPipelineDynamicStateCreateInfo.
The Vulkan specification says viewport and scissor can be nullptr if the viewport and scissor states are dynamic. We are definitely happy to make the most of this opportunity.
Use the color blend states and attachments we prepared earlier in this recipe. The VkPipelineRenderingCreateInfo is necessary for the Vulkan 1.3 dynamic rendering feature.
This code concludes the pipeline creation process. In addition to the very simple example in Chapter02/02_HelloTriangle, we created a slightly more elaborate app in Chapter02/03_GLM to demonstrate how to use multiple render pipelines to render a rotating cube with a wireframe overlay. This app uses the GLM library for matrix math. You can check it out in Chapter02/03_GLM/src/main.cpp, where it uses cmdPushConstants() to animate the cube and specialization constants to use the same set of shaders for both solid and wireframe rendering. It should look as shown in the following screenshot.
Figure 2.3: GLM usage example
There’s more…
If you are familiar with older versions of Vulkan, you might have noticed that in this recipe we completely left out any references to render passes. They are also not mentioned in any of the data structures. The reason for that is that we use Vulkan 1.3 dynamic rendering functionality, which allows VkPipeline objects to operate without needing a render pass.
In case you want to implement a similar wrapper for older versions of Vulkan and without using the VK_KHR_dynamic_rendering extension, you can maintain a “global” collection of render passes in an array inside VulkanContext and add an integer index of a corresponding render pass as a data member to RenderPipelineDynamicState. Since we can use only a very restricted number of distinct rendering passes — let’s say a maximum of 256 — the index can be saved as uint8_t. This would enable us to store them in array inside VulkanContext.
Free Chapter
