Week 2 — Vulkan Triangle, Swapchain, Shaders, and RenderDoc

Overview

This week brings up Vulkan properly and renders the first triangle. Vulkan is verbose because it is explicit: you allocate and manage everything the driver would otherwise hide, which is exactly why it teaches you how a modern GPU pipeline actually works. The first triangle is a rite of passage — it forces you to instantiate the entire chain of objects (instance, device, swapchain, render pass, pipeline, command buffers, synchronization) and understand each one’s role. By the end you should be able to explain the lifetime and purpose of every Vulkan object on screen, and inspect a frame in RenderDoc.

The payoff is conceptual leverage: once the triangle works, meshes (Week 3), offscreen sensor targets (Week 7), and instanced rendering (Week 10) are variations on the same machinery rather than new mysteries.

Readings

MGPV: instance, validation layers, physical/logical device, queues, swapchain, render pass, graphics pipeline, framebuffers, command buffers, and synchronization. Extract: what each object is for and the order of creation.
CA: GPU/CPU memory hierarchy skim. Extract: why explicit memory and command submission exist (the CPU/GPU are separate machines communicating over a bus).

Key Concepts

The object graph

Instance → physical device → logical device + queues → swapchain → image views → render pass → framebuffers → graphics pipeline (shaders + fixed-function state) → command buffers → submission. Each object has an explicit lifetime you manage. Validation layers are non-negotiable during development — they catch the misuse Vulkan otherwise silently corrupts.

The swapchain and the frame

The swapchain is a queue of images you render into and present. A frame: acquire an image, record a command buffer (begin render pass, bind pipeline, draw, end), submit to the graphics queue, present. This loop slots into Week 1’s render call.

Synchronization

CPU and GPU run asynchronously, and GPU work is itself pipelined. Semaphores order GPU-GPU dependencies (acquire → render → present); fences let the CPU wait for the GPU (don’t reuse a command buffer the GPU is still reading). Getting this wrong gives flickering, tearing, or validation errors — and it is the part that rewards careful understanding.

Shaders and the pipeline

Vertex and fragment shaders (GLSL → SPIR-V) plus fixed-function state (input assembly, rasterizer, blend, depth) compile into an immutable pipeline object. The pipeline is created once and bound per draw; this front-loads validation and makes draw calls cheap.

Theory Exercises

List the Vulkan objects needed to draw a triangle, in creation order, and state each one’s purpose in one line.
Explain the difference between a semaphore and a fence and give a concrete bug each prevents.
Describe the swapchain present loop and where acquire/submit/present synchronization points sit.
Explain why pipelines are immutable and what that buys at draw time.
Trace a vertex from buffer to screen pixel through the pipeline stages.

Implementation

Bring up Vulkan with validation layers, render a hard-coded triangle from a vertex/fragment shader, and present through the swapchain with correct semaphore/fence synchronization. Handle swapchain recreation on window resize. Integrate RenderDoc and capture a frame.

Benchmark

Four metrics this week: CPU frame time, CPU command-record time, GPU frame time (timestamp queries), and validation-on vs validation-off frame time (validation is expensive — measure the gap so you know to disable it for perf runs).

Expected baselines: a single triangle is trivially GPU-bound-free (sub-millisecond GPU time); CPU command recording dominates; validation layers add noticeable overhead. RenderDoc shows one draw call with the expected pipeline state.

Connections

This machinery is reused everywhere: Week 3 adds vertex/index/uniform buffers and depth; Week 7 renders to offscreen targets for sensors; Week 10 adds instancing and multithreaded command recording on top of the synchronization model established here. RenderDoc becomes the primary debugging tool for the rest of the course.