Vulkan for complete beginners

Home

How does Vulkan work?

Vulkan is a Graphics API at a much lower level to the hardware than OpenGL, but also meaning more control over all of the inner workings which go into displaying graphics on our monitors.

To fully understand how Vulkan is set up, I will first go through the steps to get a project up and running. Then in later chapters - break down the steps which need a deeper explanation.

It can be quite daunting when we see all the steps necessary, but hopefully by the end of this blog you will understand their place and purpose, even as a complete beginner!

First steps in Vulkan

Vulkan requires us to do a lot of setting up to begin with. I'm going to abstract the steps needed into an ordered list so you understand what's required, but don't feel like you have to understand every step mentioned thus far.

1. Window: The window which will contain our application
2. Instance: An instance of Vulkan, connecting our application and the Vulkan library
3. Surface: To present rendered images to. (Vulkan is platform agnostic so we can't present straight to the window)
4. Physical Device: We pick the physical device/s (GPUs) that we want to work with
5. Logical Device: We pick the features on the physical device/s which we want to use
6. Graphics Pipeline: Contains instructions for what to render (eg: models) and how (eg: shaders)
7. Framebuffers: Information output from the graphics pipeline which is queued into the swapchain for displaying images
8. Swap Chain: A queue of Framebuffers (usually 2 or 3) that swaps out images to display on our window

Graphics Pipeline

The graphics pipeline takes all of the data for our scene and works out what should be rendered - and also how it should be rendered.

1. Input assembler: Takes all of the raw vertex data
2. Vertex shader: Runs on every vertex & puts the model into screen space
3. Tessellation shader: Subdivides geometry, like making flat brick walls look more 3D
4. Geometry shader: A more flexible version of tessellation, although used less due to performance
5. Rasterization: Fragments* primitives (a line, point or triangle) & discards any that aren't displayed on screen or behind non-transparent objects
6. Fragment shader: Determines the framebuffers** colour & depth values for every fragment
7. Color blending: Pixels may blend to new colour if behind a transparent object such as a window or water, otherwise it may simply override it

* Fragment: Refers to the data necessary to generate a pixel in the framebuffer, eg: raster position, depth etc
** Framebuffer: An array of information containing how each pixel should be rendered held in memory

Framebuffers

In the 'First steps' chapter it was mentioned that Swap Chains are made up of Framebuffers. These are blocks of memory, output from the graphics pipeline and contain properties (aka: attachments) like a "colour buffer" or "depth buffer" which are essentially color values for each pixel that are copied from the VRAM of the gpu and presented onto the screen.

You may have heard the term 60hz as a refresh rate on your monitor - this is a standard frequency meaning 60 cycles per second. Most of the time, a swap chain will use double-buffering which uses 2 framebuffers at the same time. The framebuffer being displayed is referred to as the front-buffer, and the one being rendered to by the graphics pipeline is the "back-buffer".

It's up to the swap chain to decide when to swap these buffers around, this is referred to as V-Sync and essentially swaps them according to the refresh rate (hz) and updates the image on our monitor.

Swap Chains

Well now we know what framebuffers are and that our swap chain is full of them, next we will delve a bit deeper into swap chains. The swap chain determines a few factors as to how we finally start presenting the images produced by our graphics pipeline to our monitors. Some settings include:

Present Modes: Decides how often we should refresh the images from our swap chain

• FIFO: Causes the GPU to idle until the next refresh cycle (where the swap chain swaps the buffers around)
• Mailbox: This mode never goes idle so it consistently refreshes with the latest image, meaning lower latency but a higher power consumption
• Immediate: Ignores the v-sync completely meaning lower latency but high power consumption, and worst of all tearing*

* Tearing: a visible artefact what appears as though 2 halves of an image being displayed simultaneously

Conclusion

So to round up everything we've just gone over even more briefly:
- The graphics pipeline takes a bunch of inputs such as our models & shaders - outputs a framebuffer which sits in memory as a back-buffer until the swap chain swaps it into the front-buffer, causing the image to appear on our monitor.

The rabbit hole goes much deeper, however the aim of this blog was to give an abstracted, easy to understand overview of how Vulkan (and most GPU API's) work. I hope this gives you enough knowledge and confidence to start your very own project and good luck on your journey into graphics programming!

See also:
Next steps in Vulkan