The Vulkan Kitchen: A Visual Tour of the Graphics Pipeline

Vulkan is a modern, cross-platform way to talk to a GPU. It is an open standard from the Khronos Group, the same people behind OpenGL, and it grew out of AMD's Mantle, handed to Khronos to seed one low-level standard for the whole industry. Version 1.0 arrived in 2016.

Its defining trait is that it is explicit. Where older APIs quietly decide things for you, Vulkan hands you the controls: more work, in exchange for very low CPU overhead, honest use of many threads at once, and one model that runs the same way on desktop, mobile, and console. Section 1 unpacks that trade. Shaders are compiled ahead of time to a standard bytecode called SPIR-V, so the driver loads them directly.

You are probably already running it. Vulkan is the primary low-level graphics API on Android, where modern versions of Unity and Unreal default to it. It powers Linux and Steam Deck gaming through Proton and DXVK, which translate DirectX to Vulkan. It runs on the Nintendo Switch, and on Apple hardware through MoltenVK, which maps Vulkan onto Metal. The map below shows the spread.

Older graphics APIs like OpenGL work like ordering at a counter. You make one call, and the driver quietly decides almost everything else: which memory to use, when to synchronize, how to schedule the work. It is convenient, and for a long time it was enough.

Vulkan hands you the kitchen instead. You pick the device, allocate the memory, build the pipeline, record the commands, and manage the timing yourself. In return you get explicit, predictable, low-overhead control that works across platforms and across vendors, scales cleanly to many threads, and covers both graphics and compute. The price is verbosity: a lot of small, deliberate decisions.

Setup is four objects, met in order. The instance registers your application with the Vulkan loader, the way you register a restaurant with the city before cooking. From it you list the physical devices, the GPUs in the machine, and inspect what each one offers before choosing one. You then open a logical device, your working connection to that GPU, enabling only the features and queues you need. The logical device is where you ask for those queues, features, and extensions; the memory types and hardware limits themselves belong to the physical device, and you allocate memory through the logical device using them. Queues are the lanes you submit work to, and queue families are typed by capability, graphics, compute, or transfer, with some families also able to present to a surface. Once submitted, the GPU runs that work on its own schedule, and the panel below lets you step through the whole setup.

A typical machine has more than one option, say an integrated GPU and a discrete one. You enumerate them, read each one's queue families and memory heaps, and score them by suitability: does it support the extensions you need, does it have a queue family that can both render and present, how much device-local memory does it have. For rendering you usually pick the discrete GPU. At device creation you then ask for the specific queues you want, for example one queue from the graphics family (often family 0, which also supports present), and Vulkan hands back a VkQueue handle you submit work to later.

The surface is a platform-neutral handle to the window you draw into. It is the bridge between Vulkan and the operating system, the serving hatch between the kitchen and the dining room.

The swapchain is a small ring of images. While one image is on screen, you render into another, then hand it to the display in turn. The present mode sets the rhythm: FIFO is vsync-smooth (vsync is the display's fixed refresh beat), immediate can tear, and mailbox keeps latency low by always presenting the freshest image.

An image is the plate with the food on it: raw pixels. An image view is the serving order for that plate: which portion size to bring out (mip level), which copy from a stack of identical plates (array layer), and which kind of dish to read it as (format). Same plate, different orders.

The same image is also stored differently depending on its job right now, whether it is a render target, a sampled texture, or the thing being shown, and you transition it between those layouts explicitly. The kitchen re-plates the same dish for each step of service.

We have the kitchen, the counter we serve across, and clean plates waiting to be filled: the device, the surface, and the images from the last three sections. What we have not written down yet is the method for cooking a single frame. That method is the pipeline. The graphics pipeline is a baked recipe card. It fixes the sequence of steps your geometry passes through, in order, before a single frame runs. A few of those steps are programmable, the shaders you write, and the rest are fixed-function steps you only configure. The visualizer below walks the stages in turn.

Vulkan bakes the whole thing into a pipeline object up front, so the GPU can run it at full speed. The trade-off is rigidity: most recipe changes mean baking a new pipeline, though a few knobs stay adjustable at draw time, like viewport and scissor as dynamic state, and small values passed through push constants or uniforms.

An attachment is just a slot you draw into: an image view used as a color or depth target for the pipeline's output. The two approaches differ only in how you describe those slots. The classic approach bakes a render pass and a framebuffer ahead of time, and every pipeline is built for a specific render pass (formally, any compatible one), so changing the attachments can mean baking a new pipeline. Its subpasses can chain on-chip, which saves bandwidth on tile-based mobile GPUs. Dynamic rendering, core in Vulkan 1.3, drops both objects: you name the attachments inline when you begin rendering, and a pipeline only needs to know the attachment formats, not a specific pass. Far less to set up, and the recommended path for new code. It traded away subpasses, which mattered for mobile bandwidth, until a later extension (core in Vulkan 1.4) brought those on-chip reads back.

That is the recipe card in theory. The conveyor below maps the five stages in order, then lets you flip between the two ways of naming your attachments, the classic render pass and dynamic rendering.

A shader is the program for one programmable station. The vertex shader transforms each corner of your geometry, mapping the position your app supplied in a vertex buffer to where it lands on screen; it does not invent the geometry. The fragment shader decides the color of each pixel that the geometry covers.

You write shaders in a language like GLSL or HLSL and compile them ahead of time to SPIR-V, a standardized bytecode the driver loads directly. The driver still turns that SPIR-V into the GPU's own machine code when it loads the shader; what Vulkan removes is the driver parsing your GLSL or HLSL source, which is where vendor-specific bugs and surprises used to creep in. That is a real difference from OpenGL, which compiled shader source at runtime and left the result up to each driver.

Concretely, the build step runs a compiler (glslangValidator for GLSL, dxc for HLSL) over your shader source and writes .spv files you ship with the app. At startup each .spv becomes a VkShaderModule, and the pipeline's stage list points one stage at the vertex module's entry point and another at the fragment module's. The same SPIR-V runs on every vendor's driver; only the final compile to native code differs between them.

One shader module can hold several related shaders: each pipeline stage names the entry point it wants inside the module.

The pipeline and its shaders fix the steps. This section is about where the data those steps read actually lives. Beginners often blur several distinct ideas together, so it is worth separating them. A buffer is a described linear region of data: vertices, indices, or uniforms. On its own it is just a description.

Device memory is the actual allocation. You bind a buffer (or an image) to a region of memory yourself, choosing device-local memory for speed or host-visible memory when the CPU needs to write into it. An image is a grid of pixels, 1D, 2D, or 3D, and an image view is the serving order you read it through.

Shaders do not hold raw pointers to any of this. Instead a descriptor set is a tray of references that says this uniform here, that texture there. It holds no memory of its own: the bytes still live in the device memory you allocated and bound, and the tray only points at them. It is not the channel between one shader stage and the next either; handing a vertex shader's output to the fragment shader is the pipeline's job, not the descriptor set's. A descriptor set layout describes the slots on the tray, and a descriptor pool allocates the trays. Validation layers, meanwhile, are the optional health inspector that catches your mistakes while you develop.

In practice the order is concrete. You create a buffer with a usage and a size, ask Vulkan for its memory requirements, choose a matching memory type, allocate a block of device memory, and bind the buffer to an offset inside it. Many engines allocate one large block and suballocate every buffer and image within it. The descriptor set is then filled in with vkUpdateDescriptorSets: binding 0 might point at the uniform buffer with an offset and a range, and binding 1 at an image view plus a sampler. The set holds those references; the data still lives in the memory you allocated.

Everything is built. Now we record one frame of work and hand it to the GPU. You do not call draw directly. You record the work into a command buffer, which is allocated from a command pool: bind the pipeline, bind the descriptors, draw. The recorded ticket is then submitted to a queue, and the GPU runs it asynchronously.

The command pool and its command buffers are created once and reused. Each frame you reset a buffer and record it again. Recording just means writing that list of GPU commands onto the ticket; nothing actually runs until you submit, and the queue is only touched at that submit and at present. What changes every frame is the recorded contents, not the objects themselves.

Because the CPU and GPU run on their own clocks, you order things explicitly. Semaphores coordinate GPU-to-GPU steps: wait for the image to be acquired before rendering into it, and wait for rendering before presenting. A fence reports back to the CPU when a frame is done, so it can safely reuse that frame's command buffer and resources.

Concretely, you keep a small number of frames in flight, usually two. Each gets its own command buffer, its own uniform buffer, and its own fence, so the CPU can record the next frame into a fresh set while the GPU still works on the current one. The per-frame dance is always the same: wait on this frame's fence, acquire a swapchain image (which signals an image-available semaphore), record and submit the command buffer (waiting on image-available, signaling render-finished and the fence), then present (waiting on render-finished).

Step back and look at the global shape of the work. Everything you have met so far belongs to one of two timelines. The objects from sections 2 through 7 are built once during setup and reused every frame: that is the long setup the tutorials are famous for. (Strictly, the swapchain and the views and framebuffers derived from it are rebuilt whenever the window resizes; everything else lasts the whole program.) What remains is a short loop that runs for every single frame, and that loop is shared between two workers on their own clocks. The CPU prepares and hands off work; the GPU executes it. The map below draws that whole workflow in one picture.

Read it lane by lane. Each frame, the CPU acquires an image from the swapchain, records a command buffer, and submits it to the graphics queue. The GPU picks the work up but waits on the image-acquired semaphore, so it never draws on a plate that is still being shown, then runs your baked pipeline into that image's view and signals render-finished. Present waits on that signal before putting the plate on screen, and the fence reports back to the CPU that this frame's command buffer and resources are safe to reuse. That last hand-off closes the loop, and because the two lanes overlap, the CPU is usually already recording the next frame while the GPU still cooks the current one.

That was the shape in the abstract. Now watch the whole kitchen built and run for real on a single door: every object you have met, what it concretely is here, and exactly when it is created once or used on every frame.

That is one whole frame, start to finish. If it helps to see it differently, the panel below gathers every object into one connected graph, each where its section introduced it, with the real relationships drawn as edges and the same frame walked across it.

This was the mental model: the cast of objects, what each one is for, and how they cooperate to cook and serve one frame. None of it required writing a line of code, and that was the point.

If you keep a single picture, keep the workflow map. Build the kitchen once: instance, devices, swapchain, pipeline, buffers, command pool. Then loop forever: acquire, record, submit, present, with two semaphores ordering the GPU's work and a fence reporting back to the CPU. Every Vulkan program you will ever read, however long, is that map with the details filled in.

Do you need Vulkan? Not always. If you just want triangles on screen, OpenGL, WebGPU, or a game engine will get you there with far less ceremony. Vulkan earns its keep when you need the control: predictable CPU cost, real multithreaded recording, one explicit model across platforms. And none of this machinery is graphics-only: the same queues, command buffers, and descriptors drive compute dispatches too.

The next article actually writes the code. It walks from instance creation all the way through the draw call, and ends with a triangle on screen. With the kitchen already mapped, the code reads as a checklist rather than a mystery.