gardenWhat OpenGL forced on you, Vulkan makes you build yourself
Graphics context
The concept
The graphics context is created through a graphics API to interact with the driver, which makes the GPU render.
More precisely, a graphics context is the state object holding everything our program needs to talk to the GPU: which device we are talking to, the resources we allocated, and the current state configuration. An analogy: the API is a language (French), and the context is an active phone call held in that language.
What a Graphics Context holds
- Handles & Connections: The logical link to the physical device.
- Allocated Resources: Shaders, pipelines, vertex/index buffers, textures, descriptor sets, and command buffers in VRAM.
- Execution Queues & State: The active state (bound pipelines, viewport configs, render targets) and command queues used to send work to the GPU.
The Rendering Chain
// text
Engine (our code)
└─> Graphics API (the interface: Vulkan, DirectX, Metal)
└─> Graphics Context (state, buffers, shaders, queues)
└─> Driver (vendor's implementation)
└─> GPU (hardware)
A program can hold several contexts of the same API (one per GPU, or one per independent part of an app), but one is enough for most engines: in Vulkan, a single device context can drive many windows and record commands across multiple threads.
Linked references 4
notes that point at this one
Bufferengine
Relation with other engine concepts Graphics context: buffers are carved out of the device memory the context owns, and the queues it exposes are what carry a staging co…
Swapchainengine
Graphics context: The device and queues that own and drive the swapchain come from the graphics context.
Vulkan instancevulkan
It establishes the connection between our application and the Vulkan library — it is the first piece of our Graphics context.
Architecturegamegine
Graphics context — the RHI factory reads the GraphicsAPI enum and creates the matching Graphics context (today: the Vulkan one).