Keep Calm and Tackle Vulkan

Most people starting out with Vulkan would have looked up the code to render a triangle. You expect something short and simple. What you get instead is lines and lines of code that seem to go on forever. It’s exactly at this moment that you need to keep calm and keep going.

Yes, getting a triangle on screen can feel exhausting and really test your patience. But if you push past that initial friction, you begin to realise that this complexity comes from clarity rather than chaos.

So what exactly makes Vulkan different, and why does it matter?

What Is Vulkan?

Vulkan is a low-level programming interface designed for graphics and compute devices.

While it is most commonly associated with graphics processing units (GPUs), Vulkan is not limited to traditional graphics pipelines. It can also be implemented on other compute-capable devices, such as digital signal processors (DSPs) and specialized accelerators. Regardless, a Vulkan device is built for massive parallelism, typically combining a multithreaded processor with fixed-function hardware blocks that accelerate common graphics and compute operations.

One of Vulkan’s defining characteristics is that it is an explicit API. In older APIs like OpenGL, the drivers would do a lot of work behind the scenes like tracking the state of objects, synchronization, memory management and error checks while the application was running. This made development easier, but it also meant that even stable, well-tested applications paid a constant CPU cost for that hidden bookkeeping.

Vulkan takes a different approach. Here almost everything is the developer’s responsibility. Memory allocation, synchronization, resource lifetimes and pipeline state must all be managed explicitly.

Further, Vulkan also provides a mechanism called layers, that can intercept API calls to provide functionality such as validation, debugging, logging, and profiling. A very widely used layer is the Validation layer for correctness checks, which can be enabled during development and removed entirely from the execution path in release builds. This means that when your application is running normally, the driver does only what is absolutely necessary.

Of course, this makes Vulkan extremely verbose and somewhat fragile. It demands discipline, planning, and a solid understanding of GPU architecture. But for developers who care about performance, especially in game engines, real-time rendering, and high-end visual effects, this trade-off is often worth it.

In short: Vulkan trades convenience for performance.

The Anatomy of Vulkan

Now that you have a sense of why Vulkan looks intimidating at first glance, let’s take a look at the pieces that make it work.

Like I mentioned earlier, Vulkan is not just about graphics. A Vulkan device can support multiple categories of operations. The graphics category includes functionalities like rasterization, primitive assembly, blending, depth and stencil tests, etc. Then, it has the compute category, which allows shaders to run general-purpose compute workloads. This is useful for tasks like simulations, image processing, or anything else that benefits from massive parallelism. And finally, the transfer category, which is used for copying data around.

Importantly, the support for these categories is optional. It is entirely possible to have a Vulkan device that does not support graphics at all.

Because of this, working with Vulkan means explicitly choosing what functionality your application requires and making sure that the underlying hardware can actually support it. This is precisely what happens during Vulkan’s initial setup phase.

Vulkan introduces a hierarchy of objects that need to be configured step-by-step during the setup phase and through this you are essentially deciding what your application needs from the hardware.

Hierarchy of Functionality

Instance

The very first object you create in Vulkan is the instance, represented as VkInstance.

Unlike older APIs, Vulkan does not introduce implicit global state into your application. Instead, everything begins with a VkInstance, which acts as a software-level container for your Vulkan usage. It keeps your application’s Vulkan state isolated from other applications and libraries that may also be using Vulkan at the same time.

Creating the instance simply establishes context. It tells Vulkan who you are, what extensions or layers you want to use, and how the rest of the system should interpret your requests going forward.

As mentioned earlier, this decision also includes enabling validation, which I strongly recommend, unless you enjoy debugging blank screens at 3 a.m. To enable validation, we need to load the layer VK_LAYER_KHRONOS_validation, enable the extension VK_EXT_debug_utils and then use functions from the extension to configure our application to receive validation messages. In practice, validation is almost always enabled only in debug builds of the program and disabled in release builds.

Physical Device

A physical device represented as VkPhysicalDevice, corresponds an actual Vulkan-compatible hardware available on the system.

These devices can have different supported features, memory layouts, and queue families. Based on what your application needs, you then select the physical device that is best suited for the job. Again, this decision is entirely in the hands of the developer. Vulkan does not rank devices or choose one for you. You are expected to evaluate what matters most for your use case, whether that is specific features, performance characteristics, or memory capacity.

Logical Devices

A logical device, VkDevice, is the software construct around a physical device and represents a reservation of resources associated with a particular physical device. This includes a possible subset of the available queues on the physical device. Anything that is not explicitly enabled at this stage is simply unavailable later. It is technically possible to create multiple logical devices from a single physical device, each with its own set of enabled features and queues.

Queues

Once a logical device is created, Vulkan finally gives you a way to submit work to the GPU: queues represented as VkQueue.

Queues are the mechanism through which your application sends commands for execution. Every logical device exposes one or more queues, and each of those queues belongs to a specific queue family. A queue family represents a group of queues that share the same capabilities such as graphics, compute, or transfer and are able to process work in parallel. The number of queue families available, the capabilities of each family, and the number of queues within each family are all properties of the physical device.

And yeah, with that, you have created the instance, chosen a physical device, set up a logical device, and grabbed the queues you need. Vulkan now knows what hardware you want to use and how you intend to use it.

In the next part, we will finally start putting this setup to work and explore how Vulkan actually draws things on the screen, starting with render passes and the graphics pipeline.

Until next time, keep calm and keep exploring Vulkan.