1  // Copyright (c) 2016-2019 Khronos Group. This work is licensed under a
  2  // Creative Commons Attribution 4.0 International License; see
  3  // http://creativecommons.org/licenses/by/4.0/
  4  
  5  include::meta/VK_KHR_external_memory_capabilities.txt[]
  6  
  7  *Last Modified Date*::
  8      2016-10-17
  9  *IP Status*::
 10      No known IP claims.
 11  *Interactions and External Dependencies*::
 12    - Interacts with `<<VK_KHR_dedicated_allocation>>`.
 13    - Interacts with `<<VK_NV_dedicated_allocation>>`.
 14    - Promoted to Vulkan 1.1 Core
 15  *Contributors*::
 16    - Ian Elliot, Google
 17    - Jesse Hall, Google
 18    - James Jones, NVIDIA
 19  
 20  An application may wish to reference device memory in multiple Vulkan
 21  logical devices or instances, in multiple processes, and/or in multiple
 22  APIs.
 23  This extension provides a set of capability queries and handle definitions
 24  that allow an application to determine what types of "`external`" memory
 25  handles an implementation supports for a given set of use cases.
 26  
 27  === New Object Types
 28  
 29  None.
 30  
 31  === New Enum Constants
 32  
 33    * ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_IMAGE_FORMAT_INFO_KHR
 34    * ename:VK_STRUCTURE_TYPE_EXTERNAL_IMAGE_FORMAT_PROPERTIES_KHR
 35    * ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_BUFFER_INFO_KHR
 36    * ename:VK_STRUCTURE_TYPE_EXTERNAL_BUFFER_PROPERTIES_KHR
 37    * ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES_KHR
 38    * ename:VK_LUID_SIZE_KHR
 39  
 40  === New Enums
 41  
 42    * elink:VkExternalMemoryHandleTypeFlagBitsKHR
 43    * elink:VkExternalMemoryFeatureFlagBitsKHR
 44  
 45  === New Structs
 46  
 47    * slink:VkExternalMemoryPropertiesKHR
 48    * slink:VkPhysicalDeviceExternalImageFormatInfoKHR
 49    * slink:VkExternalImageFormatPropertiesKHR
 50    * slink:VkPhysicalDeviceExternalBufferInfoKHR
 51    * slink:VkExternalBufferPropertiesKHR
 52    * slink:VkPhysicalDeviceIDPropertiesKHR
 53  
 54  === New Functions
 55  
 56    * flink:vkGetPhysicalDeviceExternalBufferPropertiesKHR
 57  
 58  === Promotion to Vulkan 1.1
 59  
 60  All functionality in this extension is included in core Vulkan 1.1, with the
 61  KHR suffix omitted.
 62  The original type, enum and command names are still available as aliases of
 63  the core functionality.
 64  
 65  === Issues
 66  
 67  1) Why do so many external memory capabilities need to be queried on a
 68  per-memory-handle-type basis?
 69  
 70  *PROPOSED RESOLUTION*: This is because some handle types are based on
 71  OS-native objects that have far more limited capabilities than the very
 72  generic Vulkan memory objects.
 73  Not all memory handle types can name memory objects that support 3D images,
 74  for example.
 75  Some handle types cannot even support the deferred image and memory binding
 76  behavior of Vulkan and require specifying the image when allocating or
 77  importing the memory object.
 78  
 79  2) Do the slink:VkExternalImageFormatPropertiesKHR and
 80  slink:VkExternalBufferPropertiesKHR structs need to include a list of memory
 81  type bits that support the given handle type?
 82  
 83  *PROPOSED RESOLUTION*: No.
 84  The memory types that don't support the handle types will simply be filtered
 85  out of the results returned by flink:vkGetImageMemoryRequirements and
 86  flink:vkGetBufferMemoryRequirements when a set of handle types was specified
 87  at image or buffer creation time.
 88  
 89  3) Should the non-opaque handle types be moved to their own extension?
 90  
 91  *PROPOSED RESOLUTION*: Perhaps.
 92  However, defining the handle type bits does very little and does not require
 93  any platform-specific types on its own, and it's easier to maintain the
 94  bitfield values in a single extension for now.
 95  Presumably more handle types could be added by separate extensions though,
 96  and it would be midly weird to have some platform-specific ones defined in
 97  the core spec and some in extensions
 98  
 99  4) Do we need a code:D3D11_TILEPOOL type?
100  
101  *PROPOSED RESOLUTION*: No.
102  This is technically possible, but the synchronization is awkward.
103  D3D11 surfaces must be synchronized using shared mutexes, and these
104  synchronization primitives are shared by the entire memory object, so D3D11
105  shared allocations divided among multiple buffer and image bindings may be
106  difficult to synchronize.
107  
108  5) Should the Windows 7-compatible handle types be named "`KMT`" handles or
109  "`GLOBAL_SHARE`" handles?
110  
111  *PROPOSED RESOLUTION*: KMT, simply because it is more concise.
112  
113  6) How do applications identify compatible devices and drivers across
114  instance, process, and API boundaries when sharing memory?
115  
116  *PROPOSED RESOLUTION*: New device properties are exposed that allow
117  applications to correctly correlate devices and drivers.
118  A device and driver UUID that must both match to ensure sharing
119  compatibility between two Vulkan instances, or a Vulkan instance and an
120  extensible external API are added.
121  To allow correlating with Direct3D devices, a device LUID is added that
122  corresponds to a DXGI adapter LUID.
123  A driver ID is not needed for Direct3D because mismatched driver component
124  versions are not a currently supported configuration on the Windows OS.
125  Should support for such configurations be introduced at the OS level,
126  further Vulkan extensions would be needed to correlate userspace component
127  builds.