To successfully run the code featured in this and rest of chapters, your system must meet the following requirements:

A Windows computer equipped with a GPU that supports Vulkan 1.3. We recommend having a machine with at least 16 GB of RAM and a modern graphics card. The code for various chapters was tested with GTX 1080, GTX 1060, RTX 3050, and RTX 4060. Please note that Chapter 7, Ray Tracing and Hybrid Rendering, requires RTX 3050/4060 series card since it demonstrates use of ray tracing.

To get started, follow these steps:

1. Download and Install Vulkan SDK 1.3.268: Visit the LunarG website at https://sdk.lunarg.com/sdk/download/1.3.268.0/windows/VulkanSDK-1.3.268.0-Installer.exe and download the Vulkan SDK 1.3.268 installer. Run the installer to complete the installation process.
2. Install Python 3.12: Download the latest version of Python 3.12 from the official Python website and follow the installation instructions provided.
3. Clone the...

The Vulkan API, introduced in 2016 by the Khronos Group, is a low-overhead, cross-platform computing API that is the successor to OpenGL and its variants (WebGL and OpenGL ES). In fact, Vulkan was called Next Generation OpenGL (or glNext) before it was officially named Vulkan. OpenGL has been around since 1992 and it was the de facto introductory graphics API everyone learned (and learns still today). Allied with its simplicity, OpenGL is ubiquitous even today.

So, how is Vulkan different from OpenGL? It starts with its complexity. Vulkan is intended to provide application authors more control over the graphics hardware so that they can implement a solution that caters to their needs. Applications can implement solutions as simple as they want or as complex as they need. In practice, this means that the application is now responsible for controlling the hardware, making it more complex. The drivers, on the other hand, became simpler. For instance,...

Due to the many knobs Vulkan provides to control every little thing that the hardware can do, Vulkan tends to be more verbose than OpenGL. Since the control of every single aspect of the rendering process is now exposed to the application, there is simply more information that needs to be communicated with the graphics driver (mind you, the graphics driver still exists; it’s just simpler than it used to be).

The most prominent pattern used by the Vulkan API is structure-as-parameter. It is used for creating and allocating objects, querying their capabilities and information, describing layouts, and much more. In this pattern, instead of passing all possible values for the creation of an object as parameters of a function, you must stick all that information in a structure provided by the Vulkan SDK and then pass that structure as a parameter to the function.

In this recipe, you will learn how Vulkan functions are expected to be called and how to check...

The Vulkan API is extensive and many times larger than OpenGL (in any way you’d like to measure). Nonetheless, only a handful of very important objects are necessary to write many types of applications. As mentioned at the beginning of this chapter, the Vulkan API was leveled against the most demanding applications, those that need to control every single minute detail of the hardware to extract the maximum performance. But most applications don’t need all that flexibility and can get by with just the basics.

In this recipe, you will learn what Vulkan objects are and how they relate to each other.

Getting ready

Objects in Vulkan are opaque handles, and their types begin with the letters Vk. A Vulkan instance is called VkInstance, a Vulkan device is called VkDevice, and so on. Some objects need an instance of other objects to be created or allocated from. This dependency creates an implicit logical sequence as to object creation....

Volk is an open source library created by Arseny Kapoulkine that provides simple cross-platform support for loading Vulkan functions. The library provides several key features, the most important ones being automatically loading Vulkan’s function pointers and providing cross-platform support.

In this recipe, you will learn how to use Volk to load Vulkan functions and their extensions.

Getting ready

Download Volk from https://github.com/zeux/volk and add volk.c to your project and enable the preprocessor defines for your platform, VK_USE_PLATFORM_WIN32_KHR, VK_USE_PLATFORM_XLIB_KHR, VK_USE_PLATFORM_MACOS_MVK, and so on, before including volk.h.

How to do it…

Volk automatically loads Vulkan’s function pointers, so you don’t have to manually handle the details of loading them and checking for available extensions. If you use Volk in your application, do not link against the static version of...

Vulkan relies heavily on extensions. Extensions are functions and types that are part of the Vulkan Specification; they are provided in addition to the core API but aren’t guaranteed to exist for a particular version of the API. Either they are experimental or vendor- and card-specific and are not guaranteed to be present, either at compile time or runtime. Official extensions are registered with the Khronos Group and are part of the spec, so you can find their documentation there.

Extensions may be introduced to a Vulkan Specification version and later promoted to the core set of functionalities on a newer version. Or not at all! The functionality to present rendering results to a surface (such as a window on a GUI), for example, is still an extension even in Vulkan 1.3 (the most recent version as of the writing of this book). If you are curious, here’s a link to it, the VK_KHR_surface device extension: https://registry.khronos.org...

In the spirit of a high-performant, low-overhead API, Vulkan does not perform error-checking by default. Doing so would incur a performance penalty, which may be unacceptable for some applications. On the other hand, due to Vulkan’s complexity, it is very easy for the application to make mistakes.

To help application authors detect errors, Vulkan provides layers, which can be enabled during development and later disabled for shipping. That combination isn’t mandatory, as developers don’t have to enable error-detecting layers for testing nor disable them for shipping, although that is the most common scenario.

In this recipe, we will introduce what Vulkan layers are and how their messages are presented, as well as offer tips on how to learn more about the meaning of those messages.

Getting ready

Layers are provided with the Vulkan SDK, so if you are using Vulkan, chances are you also have access to layers...

Enabling an instance layer is as easy as providing its name as a const char * to the instance creation function. Unfortunately, not all layers exist in all implementations, and we need to check the available ones before trying to enable them.

In this recipe, you will learn how to enumerate the available instance layers and how to transform them into strings so that they are easier to manage.

Getting ready

The code snippets shown in this section are part of our Context class.. It encapsulates most of the initialization and object creation functions.

How to do it…

Checking the available extensions is easy to do:

1. First, you need to query the number of extensions using the vkEnumerateInstanceLayerProperties function, create an array of VkLayerProperties big enough to store all extensions, and request their data by issuing a call to the same function again, like this:

   uint32_t instanceLayerCount{0};
   VK_CHECK(vkEnumerateInstanceLayerProperties...

The same process of filtering requested layers against available ones should be repeated for instance extensions.

In this recipe, you will learn how to obtain available instance extensions, how to store them as strings, and how to convert them to pointers to characters so that they can be passed to the Vulkan API.

Getting ready

The process is very similar to the one described in the previous recipe, which also includes a utility function to perform an intersection of the available layers and the requested ones.

How to do it…

Obtaining a list of extensions is as easy as obtaining the available layers.

1. First, call vkEnumerateInstanceExtensionProperties twice, once to determine how many extensions are available and then one more time to fetch the extensions:

   uint32_t extensionsCount{0};
   vkEnumerateInstanceExtensionProperties(
       nullptr, &extensionsCount, nullptr);
   std::vector<VkExtensionProperties...

To start using Vulkan, we need to create a Vulkan instance. One can think of a Vulkan instance as a way of initializing the Vulkan library. To create one, you need to provide a set of required and optional information such as application name, engine name, version, and a list of desired layers and extensions.

In this recipe, you will learn how to create a Vulkan instance.

Getting ready

Instantiating the VkApplicationInfo structure used to create an instance requires the version of the application and the Vulkan API version. The former can be created using the VK_MAKE_VERSION macro, while the latter can be provided as one of the preprocessor definitions available in the SDK.

How to do it…

With all of those in hand, all we need to do is create a Vulkan instance:

1. Create an instance of the VkApplicationInfo structure first:

   const VkApplicationInfo applicationInfo_ = {
       .sType = VK_STRUCTURE_TYPE_APPLICATION_INFO...

Just as in OpenGL, presenting the final render output to the screen needs support from the windowing system and is platform-dependent. For this reason, the Vulkan Core API does not contain functions to render the final image to the screen. Those functions and types are extensions. For this recipe, we’ll use the VK_KHR_surface and VK_KHR_swapchain extensions. We will cover only the Windows case here and use the VK_KHR_win32_surface extension.

In this recipe, you will learn how to create a surface for presenting the final output of your rendering.

Getting ready

The first step in the process of rendering an image onto the screen starts with the creation of a VkSurfaceKHR object. Since this object is needed while reserving queues from a physical device, this step is done after the instance has been created but before the physical devices are enumerated and before the device is created, as the device needs information about which queue families we will...

Before we can create a device in Vulkan, we need to select a suitable physical device, as a system may have multiple Vulkan-capable GPUs and we want to choose one with the capabilities required by our application. To do this, we need to enumerate all available physical devices on the system. This can be achieved by calling the vkEnumeratePhysicalDevices function, which returns a list of all physical devices on the system that support the Vulkan API. Once we have the list of physical devices, we can inspect their properties and features using the vkGetPhysicalDeviceProperties and vkGetPhysicalDeviceFeatures functions to determine if they have the required capabilities. Finally, we can choose the most suitable physical device and use it to create a logical device through the vkCreateDevice function.

In this recipe, you will learn how to enumerate all Vulkan-capable devices present in the system so that you can choose one that best fits your needs...

In Vulkan, a physical device can have one or more queue families, where each queue family represents a set of command queues that share certain properties, such as capabilities or usage. Figure 1.3 depicts a fictional set of families and their queues:

Figure 1.3 – Queue families and their queues

Each queue family supports a specific set of operations and commands that can be executed in parallel. For example, there may be a graphics queue family, a compute queue family, and a transfer queue family, each optimized for different types of operations.

In this recipe, you will learn how to retrieve the properties of a queue family and where they are stored in the code in the repository.

Getting ready

In the repository provided with this book, queue families and their properties are stored and managed by the VulkanCore::PhysicalDevice class.

How to do it…

Each queue family has its own set...

Physical device extensions must be explicitly enabled by the application and may only be available on specific physical devices or device drivers. It’s important to check for the availability of required extensions and to gracefully handle situations where extensions are not supported.

In this recipe, you will learn how to enumerate all physical device extensions and how to convert and store them to strings for later use.

Getting ready

Enumerating physical device extensions is managed by the VulkanCore::PhysicalDevice class.

How to do it…

Obtaining all physical device extensions for a physical device is simple. Here, we also provide code to store them as strings so that they are easier to work with.

1. Enumerating all physical device extensions is done by using the vkEnumerateDeviceExtensionProperties function. The result is an array of VkExtensionProperties. This structure contains information such as the extension...

In Vulkan, a queue family is a group of one or more queues that share common properties, such as the type of operations they can perform. When creating a Vulkan device, we must specify which queue families we want to use and how many queues of each family we need.

For rendering and presentation, we typically need at least one graphics queue family, which is responsible for executing graphics commands. Additionally, we may require a compute queue family for executing compute workloads and a transfer queue family for handling data transfers.

In this recipe, you will learn how to find queue families based on their properties and how to select a queue family that supports presentation, which can be used to present the final render output on the screen.

Getting ready

In the repository, reserving queues is encapsulated by the VulkanCore::PhysicalDevice class.

How to do it…

One additional step necessary before creating a Vulkan device is to...

A Vulkan device is a logical representation of a physical GPU. It’s an object that is associated with a selected physical device (an existing GPU in the system) and is used to perform all graphics and compute operations. The device also provides access to physical GPU capabilities through queues. Queues are used to submit commands to the GPU, such as draw calls or memory transfers. The device also provides access to other Vulkan objects, such as pipelines, buffers, and images.

In this recipe, you will learn how to create a Vulkan logical device.

Getting ready

The code in this recipe is available as part of the VulkanCore::Context class in the repository. The Context class represents a Vulkan logical device.

How to do it…

To create a Vulkan device, we need to provide a physical device and the indices of the queue families we want to use. Using this information, we can create a vector of VkDeviceQueueCreateInfo structures...

Once the logical device has been created, we need to obtain the handle to queues. That is accomplished with the vkGetDeviceQueue function. This handle will be used to submit command buffers for processing on the GPU.

In this recipe, you will learn how to obtain the handle to a Vulkan queue.

Getting ready

In the repository, all queues are retrieved and stored by the VulkanCore::Context class. That class maintains a list for each type of queue: graphics, compute, transfer, and sparse, along with a special queue for presentation.

How to do it…

To retrieve the handle to a queue, just call the vkGetDeviceQueue function with the queue family index and the queue index:

VkQueue queue{VK_NULL_HANDLE};
uint32_t queueFamilyIndex; // valid queue family
vkGetDeviceQueue(device, queueFamilyIndex, 0, &queue);

Knowing which queue families are available is not enough. Once we determine which queues are available and the queues we need...