Safe Haskell | Safe-Inferred |
---|---|
Language | Haskell2010 |
Name
VK_KHR_external_memory_capabilities - instance extension
VK_KHR_external_memory_capabilities
- Name String
VK_KHR_external_memory_capabilities
- Extension Type
- Instance extension
- Registered Extension Number
- 72
- Revision
- 1
- Ratification Status
- Ratified
- Extension and Version Dependencies
- VK_KHR_get_physical_device_properties2
- Deprecation State
- Promoted to Vulkan 1.1
- Contact
Other Extension Metadata
- Last Modified Date
- 2016-10-17
- IP Status
- No known IP claims.
- Interactions and External Dependencies
- Interacts with
VK_KHR_dedicated_allocation
. - Interacts with
VK_NV_dedicated_allocation
. - Promoted to Vulkan 1.1 Core
- Interacts with
- Contributors
- Ian Elliott, Google
- Jesse Hall, Google
- James Jones, NVIDIA
Description
An application may wish to reference device memory in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension provides a set of capability queries and handle definitions that allow an application to determine what types of “external” memory handles an implementation supports for a given set of use cases.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Commands
New Structures
ExternalMemoryPropertiesKHR
PhysicalDeviceExternalBufferInfoKHR
Extending
ImageFormatProperties2
:Extending
PhysicalDeviceImageFormatInfo2
:Extending
PhysicalDeviceProperties2
:
New Enums
New Bitmasks
New Enum Constants
KHR_EXTERNAL_MEMORY_CAPABILITIES_SPEC_VERSION
LUID_SIZE_KHR
Extending
ExternalMemoryFeatureFlagBits
:Extending
ExternalMemoryHandleTypeFlagBits
:EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT_KHR
EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_KMT_BIT_KHR
EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_HEAP_BIT_KHR
EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_RESOURCE_BIT_KHR
EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR
EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR
EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR
Extending
StructureType
:
Issues
1) Why do so many external memory capabilities need to be queried on a per-memory-handle-type basis?
PROPOSED RESOLUTION: This is because some handle types are based on OS-native objects that have far more limited capabilities than the very generic Vulkan memory objects. Not all memory handle types can name memory objects that support 3D images, for example. Some handle types cannot even support the deferred image and memory binding behavior of Vulkan and require specifying the image when allocating or importing the memory object.
2) Do the ExternalImageFormatPropertiesKHR
and
ExternalBufferPropertiesKHR
structs need to include a list of memory
type bits that support the given handle type?
PROPOSED RESOLUTION: No. The memory types that do not support the
handle types will simply be filtered out of the results returned by
getImageMemoryRequirements
and
getBufferMemoryRequirements
when a set
of handle types was specified at image or buffer creation time.
3) Should the non-opaque handle types be moved to their own extension?
PROPOSED RESOLUTION: Perhaps. However, defining the handle type bits does very little and does not require any platform-specific types on its own, and it is easier to maintain the bitfield values in a single extension for now. Presumably more handle types could be added by separate extensions though, and it would be midly weird to have some platform-specific ones defined in the core spec and some in extensions
4) Do we need a D3D11_TILEPOOL
type?
PROPOSED RESOLUTION: No. This is technically possible, but the synchronization is awkward. D3D11 surfaces must be synchronized using shared mutexes, and these synchronization primitives are shared by the entire memory object, so D3D11 shared allocations divided among multiple buffer and image bindings may be difficult to synchronize.
5) Should the Windows 7-compatible handle types be named “KMT” handles or “GLOBAL_SHARE” handles?
PROPOSED RESOLUTION: KMT, simply because it is more concise.
6) How do applications identify compatible devices and drivers across instance, process, and API boundaries when sharing memory?
PROPOSED RESOLUTION: New device properties are exposed that allow applications to correctly correlate devices and drivers. A device and driver UUID that must both match to ensure sharing compatibility between two Vulkan instances, or a Vulkan instance and an extensible external API are added. To allow correlating with Direct3D devices, a device LUID is added that corresponds to a DXGI adapter LUID. A driver ID is not needed for Direct3D because mismatched driver component versions are not currently supported on the Windows OS. Should support for such configurations be introduced at the OS level, further Vulkan extensions would be needed to correlate userspace component builds.
Version History
Revision 1, 2016-10-17 (James Jones)
- Initial version
See Also
LUID_SIZE_KHR
,
ExternalBufferPropertiesKHR
, ExternalImageFormatPropertiesKHR
,
ExternalMemoryFeatureFlagBitsKHR
, ExternalMemoryFeatureFlagsKHR
,
ExternalMemoryHandleTypeFlagBitsKHR
,
ExternalMemoryHandleTypeFlagsKHR
, ExternalMemoryPropertiesKHR
,
PhysicalDeviceExternalBufferInfoKHR
,
PhysicalDeviceExternalImageFormatInfoKHR
,
PhysicalDeviceIDPropertiesKHR
,
getPhysicalDeviceExternalBufferPropertiesKHR
Document Notes
For more information, see the Vulkan Specification
This page is a generated document. Fixes and changes should be made to the generator scripts, not directly.
Documentation
pattern EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR :: ExternalMemoryHandleTypeFlagBits Source #
pattern EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR :: ExternalMemoryHandleTypeFlagBits Source #
pattern EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT_KHR :: ExternalMemoryHandleTypeFlagBits Source #
pattern EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_KMT_BIT_KHR :: ExternalMemoryHandleTypeFlagBits Source #
pattern EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_RESOURCE_BIT_KHR :: ExternalMemoryHandleTypeFlagBits Source #
pattern LUID_SIZE_KHR :: Integral a => a Source #
getPhysicalDeviceExternalBufferPropertiesKHR :: forall {a :: [Type]} {io}. (Extendss PhysicalDeviceExternalBufferInfo a, PokeChain a, MonadIO io) => PhysicalDevice -> PhysicalDeviceExternalBufferInfo a -> io ExternalBufferProperties Source #
pattern KHR_EXTERNAL_MEMORY_CAPABILITIES_SPEC_VERSION :: forall a. Integral a => a Source #
type KHR_EXTERNAL_MEMORY_CAPABILITIES_EXTENSION_NAME = "VK_KHR_external_memory_capabilities" Source #
pattern KHR_EXTERNAL_MEMORY_CAPABILITIES_EXTENSION_NAME :: forall a. (Eq a, IsString a) => a Source #