From fc9f7610703d73f45c38dd07cb583094fa02c8f9 Mon Sep 17 00:00:00 2001 From: Courtney Goeltzenleuchter Date: Sun, 14 Feb 2016 10:48:22 -0700 Subject: loader: Add images to interface Doc --- loader/LoaderAndLayerInterface.md | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'loader/LoaderAndLayerInterface.md') diff --git a/loader/LoaderAndLayerInterface.md b/loader/LoaderAndLayerInterface.md index 4901fea7..f5a222c0 100644 --- a/loader/LoaderAndLayerInterface.md +++ b/loader/LoaderAndLayerInterface.md @@ -75,6 +75,7 @@ first layer’s vkCreateInstance which will call the next finally terminating in the loader again where this function calls every ICD’s vkCreateInstance and saves the results. This allows every enabled layer for this chain to set up what it needs based on the VkInstanceCreateInfo structure from the application. +![Instance call chain](/images/instance_call_chain.png) This also highlights some of the complexity the loader must manage when using instance chains. As shown here, the loader must aggregate information from @@ -85,6 +86,7 @@ Device chains are created at vkCreateDevice and are generally simpler because they deal with only a single device and the ICD can always be the terminator of the chain. The below diagram also illustrates how layers (either device or instance) can skip intercepting any given Vulkan entry point. +![Chain skipping layers](/images/chain_skipping_layers.png) Application interface to loader ------------------------------- @@ -240,6 +242,8 @@ vkGetDeviceProcAddr will only work with the specific VkDevice it was created for, using it with another device has undefined results. For extensions, Get\*ProcAddr will often be the only way to access extension API features. +![Get*ProcAddr efficiency](/images/get_proc_addr.png) + Vulkan Installable Client Driver interface with the loader ---------------------------------------------------------- -- cgit v1.2.3