Webinar Recap: Vulkan Loader Deep Dive

In March, we hosted a webinar that gave viewers a deep-dive presentation on the Vulkan Loader, presented by Mark Young and Lenny Komow from LunarG. They discussed different aspects of the loader, including its overall design, and features including dispatchable objects, instance versus device objects and commands, trampolines and terminators, extension handling, and much more. To get all the details, view the webinar here, or check out our five key points below:

1. Loaders. There are actually two different Vulkan loaders: for Android, which is closed-sourced, and is available starting with Nougat; the other is for desktop systems, using the same source for Linux and Windows. Both implementations conform to a single interface document. The desktop loader responds to various environmental variables that can be used to override default settings to help diagnose issues or force certain behaviors.
2. Objects. Instance-level objects and commands are high-level and must work with all available installable client drivers (ICDs), which makes every physical device on a system available to an application. There are also device-level objects and commands that target one physical device managed by one specific ICD.
3. Trampolines and terminators. Trampolines are the initial loader entry point for a Vulkan command, and trigger the appropriate call chain. All commands accessed through the loader utilize a trampoline. Instance-level commands have a corresponding function called a terminator that is responsible for distributing all calls to multiple ICDs after any layer interaction is complete.
4. Manifest files. Manifest files are JSON-formatted files that are used by the desktop loader to reduce security risks by listing all important properties to the application and loader. The manifest file will only initiate interaction with the ICD or layer when enabled by the user.
5. Call chains. Instance-level and device-level objects and commands have different call chains, as shown in the diagram below. An Instance call chain includes both a trampoline and terminator; whereas the device call chain only requires a trampoline for most cases. Additional performance may be seen by using vkGetDeviceProcAddr() to generate your own device function table thereby skipping the loader's trampoline and allowing your application to talk directly to the first enabled layer or ICD.

Example Call Chains

For more information about the Vulkan Loader and Validation Layers interface, visit the Khronos Vulkan page, the LunarG LunarXchange website’s Docs section, or you can access the guide that Mark references on GitHub. Stay tuned for upcoming webinars and other events.