VK_NV_external_memory_capabilities(3)

# VK_NV_external_memory_capabilities(3) Manual Page

## Name

VK_NV_external_memory_capabilities - instance extension

Loading… please wait.

## Registered Extension Number

56

## Revision

1

## Ratification Status

Not ratified

## Extension and Version Dependencies

None

## Deprecation State

- Deprecated by VK_KHR_external_memory_capabilities extension

  - Which in turn was promoted to Vulkan 1.1

## Contact

- James Jones cubanismo

## Other Extension Metadata

Last Modified Date

  2016-08-19

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Interacts with Vulkan 1.1.

  - Interacts with `VK_KHR_dedicated_allocation`.

  - Interacts with `VK_NV_dedicated_allocation`.

Contributors

  - James Jones, NVIDIA

## Description

Applications may wish to import memory from the Direct 3D API, or export memory to other Vulkan instances. This extension provides a set of capability queries that allow applications determine what types of win32 memory handles an implementation supports for a given set of use cases.

## New Commands

- vkGetPhysicalDeviceExternalImageFormatPropertiesNV

## New Structures

- VkExternalImageFormatPropertiesNV

## New Enums

- VkExternalMemoryFeatureFlagBitsNV

- VkExternalMemoryHandleTypeFlagBitsNV

## New Bitmasks

- VkExternalMemoryFeatureFlagsNV

- VkExternalMemoryHandleTypeFlagsNV

## New Enum Constants

- `VK_NV_EXTERNAL_MEMORY_CAPABILITIES_EXTENSION_NAME`

- `VK_NV_EXTERNAL_MEMORY_CAPABILITIES_SPEC_VERSION`

## Issues

1) Why do so many external memory capabilities need to be queried on a per-memory-handle-type basis?

RESOLVED: 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) Does the VkExternalImageFormatPropertiesNV struct need to include a list of memory type bits that support the given handle type?

RESOLVED: No. The memory types that do not support the handle types will simply be filtered out of the results returned by vkGetImageMemoryRequirements when a set of handle types was specified at image creation time.

3) Should the non-opaque handle types be moved to their own extension?

RESOLVED: 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 bitmask 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

## Version History

- Revision 1, 2016-08-19 (James Jones)

  - Initial version

## See Also

VkExternalImageFormatPropertiesNV, VkExternalMemoryFeatureFlagBitsNV, VkExternalMemoryFeatureFlagsNV, VkExternalMemoryHandleTypeFlagBitsNV, VkExternalMemoryHandleTypeFlagsNV, vkGetPhysicalDeviceExternalImageFormatPropertiesNV

## 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.

## Copyright

Copyright 2014-2024 The Khronos Group Inc.

SPDX-License-Identifier: CC-BY-4.0