1// Copyright 2021-2023 The Khronos Group Inc. 2// 3// SPDX-License-Identifier: CC-BY-4.0 4 5= Proposal Template 6:toc: left 7:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/ 8:sectnums: 9 10This document proposes an extension to allow the loader to understand 11driver layering, for improving physical device sorting. 12 13== Problem Statement 14 15The Vulkan loader is able to sort physical devices according to 16platform-specific criteria. For example, on Windows, the loader uses LUIDs 17to put physical devices in the same order as DXGI adapters. However, it is 18possible to have multiple Vulkan drivers that provide support for the same 19physical device, for example, where one is a "`native`" vendor-provided 20implementation and another is a "`layered`" implementation on top of a 21different API. Examples of layered implementations would include VulkanOn12 22(aka Dozen), layered on D3D12, and MoltenVK, layered on Metal. 23 24On a system where a physical device has two possible drivers, the sort 25order between them is currently unspecified. An ideal sort order 26should place any native/un-layered drivers sorted-before any layered 27drivers, as it should be expected that native drivers will provide more 28functionality and higher performance, since layering inherently adds 29overhead. But the loader has no way of knowing which driver to prefer. 30 31An additional problem that is not addressed by this specification is the 32case where you have multiple "`native`" drivers for a single physical device. 33In that case, the sort order remains unspecified, as a correct ordering 34between drivers is non-obvious. 35 36== Solution Space 37 38Options that were considered include: 39* Special-casing well-known layered drivers in the Vulkan loader. 40* Extending the Loader-ICD interface to identify layered drivers. 41* Providing an extension to allow layered drivers to self-identify. 42 43The latter solution is the more general, and also has the benefit of 44allowing applications to understand when they are running on a layered 45driver. 46 47== Proposal 48 49The following properties are exposed by the `VK_MSFT_layered_driver` 50extension: 51[source,c] 52---- 53typedef enum VkLayeredDriverUnderlyingApiMSFT { 54 VK_LAYERED_DRIVER_UNDERLYING_API_NONE_MSFT, 55 VK_LAYERED_DRIVER_UNDERLYING_API_D3D12_MSFT, 56} VkLayeredDriverUnderlyingApiMSFT; 57 58typedef struct VkPhysicalDeviceLayeredDriverPropertiesMSFT { 59 VkStructureType sType; 60 const void* pNext; 61 VkLayeredDriverUnderlyingApiMSFT underlyingAPI; 62} VkPhysicalDeviceLayeredDriverPropertiesMSFT; 63---- 64 65Layered drivers should implement this extension. The Vulkan loader can then 66be updated to query for the this structure. If the `underlyingAPI` is not 67`NONE`, then the driver should be considered layered. The specific value of 68`underlyingAPI` is simply informational for applications to query if they 69so choose. 70 71== Issues 72 73=== RESOLVED: Is a string the right way to identify an underlying API? 74 75No, an enum is a much better solution. The same conclusion was already 76reached with the `VkDriverId` enum. 77 78== Further Functionality 79 80Additional properties of the layering implementation, such as underlying 81API object pointers, could be exposed, but considering that the nature of 82those will depend on the underlying API, it seems like those should be 83exposed via separate extensions, if at all. 84 85It might make sense to add things like driver version for the underlying 86driver, since the version information exposed through existing properties 87would refer to the version of layered implementation. 88