Chapter X: going further
This chapter is future work (ETA October 2025)
This is a lazy chapter whose only aim is to provide some pointers.
A. Good practices
Using Vulkan:
- AMD's RDNA performance guide
- Nvidia's Vulkan Dos and Don'ts
- Arm's best practices resources for Vulkan
- Writing an efficient Vulkan renderer (blog post by Arseny Kapoulkine)
B. The Vulkan loader architecture
By default, every Vulkan function call that we emit goes through the Vulkan loader, which is a library that implements the instance-level functionality of Vulkan and manages the available drivers (where the device-level functionality is implemented). The loader also manages dispatch tables to forward function calls to the right address (one for the instance functions created at vkCreateInstance time, and an additional one per device created at vkCreateDevice time).
Even when we do something that looks like statical linking of Vulkan, we are actually only statically linking a small library that loads the Vulkan loader dynamically for us.
Note that going through the loader makes loading not as direct as it could be. For best performance, we should setup our own dispatch table (using the vkGetInstanceProcAddr and vkGetDeviceProcAddr functions), as described here. Alternatively, we can use the thirdparty Volk meta-loader, which does this automatically for us and handles layers and extensions correctly. We should get an performance improvement in the low percents that way (Volk's original author, Arseny Kapoulkine estimates it to be in the range of 1 to 5% for typical Vulkan applications, as detailed here).
C. Memory allocation
Vulkan Memory Allocator