HORIZON HASKELLDocslts/ghc-9.14.x3e2d5682026-10-11Search names, modules, packages, or :: a typeCtrl K

GHC 9.14.1 · lts/ghc-9.14.x · 3e2d568 · 2026-10-11

Modulevulkan-3.27GHC2021

Vulkan.Extensions.VK_KHR_external_memory_win32

Name

VK_KHR_external_memory_win32 - device extension

VK_KHR_external_memory_win32

Name String

VK_KHR_external_memory_win32

Extension Type

Device extension

Registered Extension Number

74

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies

VK_KHR_external_memory

or

Vulkan Version 1.1

Contact

Other Extension Metadata

Last Modified Date

2016-10-21

IP Status

No known IP claims.

Contributors

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Carsten Rohde, 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 enables an application to export Windows handles from Vulkan memory objects and to import Vulkan memory objects from Windows handles exported from other Vulkan memory objects or from similar resources in other APIs.

New Commands

New Structures

New Enum Constants

Issues

1) Do applications need to call CloseHandle() on the values returned from getMemoryWin32HandleKHR when handleType is EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR?

RESOLVED: Yes. A successful get call transfers ownership of the handle to the application. Destroying the memory object will not destroy the handle or the handle’s reference to the underlying memory resource. Unlike file descriptor opaque handles, win32 opaque handle ownership can not be transferred back to a driver by an import operation.

2) Should the language regarding KMT/Windows 7 handles be moved to a separate extension so that it can be deprecated over time?

RESOLVED: No. Support for them can be deprecated by drivers if they choose, by no longer returning them in the supported handle types of the instance level queries.

3) How should the valid size and memory type for windows memory handles created outside of Vulkan be specified?

RESOLVED: The valid memory types are queried directly from the external handle. The size is determined by the associated image or buffer memory requirements for external handle types that require dedicated allocations, and by the size specified when creating the object from which the handle was exported for other external handle types.

Version History

  • Revision 1, 2016-10-21 (James Jones)

    • Initial revision

See Also

No cross-references are available

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.

  • 10 types
  • 2 values
  • Packagevulkan-3.27
  • Exports14
  • LanguageGHC2021
  • LicenceBSD-3-Clause
  • SourceVK_KHR_external_memory_win32.hs
valuegetMemoryWin32HandleKHR
  1. :: MonadIO io
  2. => Device

    device is the logical device that created the device memory being exported.

    device must be a valid Device handle

  3. -> MemoryGetWin32HandleInfoKHR

    pGetWin32HandleInfo is a pointer to a MemoryGetWin32HandleInfoKHR structure containing parameters of the export operation.

    pGetWin32HandleInfo must be a valid pointer to a valid MemoryGetWin32HandleInfoKHR structure

  4. -> io HANDLE
#

vkGetMemoryWin32HandleKHR - Get a Windows HANDLE for a memory object

Description

For handle types defined as NT handles, the handles returned by getMemoryWin32HandleKHR are owned by the application and hold a reference to their payload. To avoid leaking resources, the application must release ownership of them using the CloseHandle system call when they are no longer needed.

Non-NT handle types do not add a reference to their associated payload. If the original object owning the payload is destroyed, all resources and handles sharing that payload will become invalid.

Return Codes

Success
Failure

See Also

VK_KHR_external_memory_win32, Device, MemoryGetWin32HandleInfoKHR

valuegetMemoryWin32HandlePropertiesKHR
  1. :: MonadIO io
  2. => Device

    device is the logical device that will be importing handle.

    device must be a valid Device handle

  3. -> ExternalMemoryHandleTypeFlagBits

    handleType is a ExternalMemoryHandleTypeFlagBits value specifying the type of the handle handle.

    handleType must not be one of the handle types defined as opaque

    handleType must be a valid ExternalMemoryHandleTypeFlagBits value

  4. -> HANDLE

    handle is the handle which will be imported.

    handle must point to a valid Windows memory handle

  5. -> io MemoryWin32HandlePropertiesKHR
#

vkGetMemoryWin32HandlePropertiesKHR - Get Properties of External Memory Win32 Handles

Return Codes

Success
Failure

See Also

VK_KHR_external_memory_win32, Device, ExternalMemoryHandleTypeFlagBits, MemoryWin32HandlePropertiesKHR

datadata ImportMemoryWin32HandleInfoKHR
#

VkImportMemoryWin32HandleInfoKHR - Import Win32 memory created on the same physical device

Description

Importing memory object payloads from Windows handles does not transfer ownership of the handle to the Vulkan implementation. For handle types defined as NT handles, the application must release handle ownership using the CloseHandle system call when the handle is no longer needed. For handle types defined as NT handles, the imported memory object holds a reference to its payload.

Non-NT handle import operations do not add a reference to their associated payload. If the original object owning the payload is destroyed, all resources and handles sharing that payload will become invalid.

Applications can import the same payload into multiple instances of Vulkan, into the same instance from which it was exported, and multiple times into a given Vulkan instance. In all cases, each import operation must create a distinct DeviceMemory object.

Valid Usage

Valid Usage (Implicit)

Structure Chaining

Extends the structure

See Also

VK_KHR_external_memory_win32, ExternalMemoryHandleTypeFlagBits, StructureType

Constructors

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero
datadata ExportMemoryWin32HandleInfoKHR
#

VkExportMemoryWin32HandleInfoKHR - Structure specifying additional attributes of Windows handles exported from a memory

Description

If ExportMemoryAllocateInfo is not included in the same pNext chain, this structure is ignored.

If ExportMemoryAllocateInfo is included in the pNext chain of MemoryAllocateInfo with a Windows handleType, but either ExportMemoryWin32HandleInfoKHR is not included in the pNext chain, or it is included but pAttributes is set to NULL, default security descriptor values will be used, and child processes created by the application will not inherit the handle, as described in the MSDN documentation for “Synchronization Object Security and Access Rights”1. Further, if the structure is not present, the access rights used depend on the handle type.

For handles of the following types:

The implementation must ensure the access rights allow read and write access to the memory.

1

https://docs.microsoft.com/en-us/windows/win32/sync/synchronization-object-security-and-access-rights

Valid Usage

Valid Usage (Implicit)

  • If pAttributes is not NULL, pAttributes must be a valid pointer to a valid SECURITY_ATTRIBUTES value

Structure Chaining

Extends the structure

See Also

VK_KHR_external_memory_win32, StructureType

Constructors

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero
datadata MemoryWin32HandlePropertiesKHR
#

VkMemoryWin32HandlePropertiesKHR - Properties of External Memory Windows Handles

Valid Usage (Implicit)

See Also

VK_KHR_external_memory_win32, StructureType, getMemoryWin32HandlePropertiesKHR

Constructors

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero
datadata MemoryGetWin32HandleInfoKHR
#

VkMemoryGetWin32HandleInfoKHR - Structure describing a Win32 handle memory export operation

Description

The properties of the handle returned depend on the value of handleType. See ExternalMemoryHandleTypeFlagBits for a description of the properties of the defined external memory handle types.

Valid Usage

  • If handleType is defined as an NT handle, getMemoryWin32HandleKHR must be called no more than once for each valid unique combination of memory and handleType

  • handleType must be defined as an NT handle or a global share handle

Valid Usage (Implicit)

See Also

VK_KHR_external_memory_win32, DeviceMemory, ExternalMemoryHandleTypeFlagBits, StructureType, getMemoryWin32HandleKHR

Constructors

Instances6Eq, Show, Storable, FromCStruct, ToCStruct, Zero