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

GHC 9.14.1 · lts/ghc-9.14.x · 45dd537 · 2026-10-11

Modulevulkan-3.27GHC2021

Vulkan.Extensions.VK_NV_external_memory_capabilities

Name

VK_NV_external_memory_capabilities - instance extension

VK_NV_external_memory_capabilities

Name String

VK_NV_external_memory_capabilities

Extension Type

Instance extension

Registered Extension Number

56

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies

None

Deprecation State
Contact

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

New Structures

New Enums

New Bitmasks

New Enum Constants

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 ExternalImageFormatPropertiesNV structure 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 getImageMemoryRequirements 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

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.

  • 7 types
  • 1 value
  • Packagevulkan-3.27
  • Exports17
  • LanguageGHC2021
  • LicenceBSD-3-Clause
  • SourceVK_NV_external_memory_capabilities.hs
valuegetPhysicalDeviceExternalImageFormatPropertiesNV
  1. :: MonadIO io
  2. => PhysicalDevice

    physicalDevice is the physical device from which to query the image capabilities

    physicalDevice must be a valid PhysicalDevice handle

  3. -> Format

    format is the image format, corresponding to ImageCreateInfo::format.

    format must be a valid Format value

  4. -> ImageType

    type is the image type, corresponding to ImageCreateInfo::imageType.

    type must be a valid ImageType value

  5. -> ImageTiling

    tiling is the image tiling, corresponding to ImageCreateInfo::tiling.

    tiling must be a valid ImageTiling value

  6. -> ImageUsageFlags

    usage is the intended usage of the image, corresponding to ImageCreateInfo::usage.

    usage must be a valid combination of ImageUsageFlagBits values

    usage must not be 0

  7. -> ImageCreateFlags

    flags is a bitmask describing additional parameters of the image, corresponding to ImageCreateInfo::flags.

    flags must be a valid combination of ImageCreateFlagBits values

  8. -> "externalHandleType" ::: ExternalMemoryHandleTypeFlagsNV

    externalHandleType is either one of the bits from ExternalMemoryHandleTypeFlagBitsNV, or 0.

    externalHandleType must not have more than one bit set

    externalHandleType must be a valid combination of ExternalMemoryHandleTypeFlagBitsNV values

  9. -> io ExternalImageFormatPropertiesNV
#

vkGetPhysicalDeviceExternalImageFormatPropertiesNV - Determine image capabilities compatible with external memory handle types

Description

If externalHandleType is 0, pExternalImageFormatProperties->imageFormatProperties will return the same values as a call to getPhysicalDeviceImageFormatProperties, and the other members of pExternalImageFormatProperties will all be 0. Otherwise, they are filled in as described for ExternalImageFormatPropertiesNV.

Return Codes

Success
Failure

See Also

VK_NV_external_memory_capabilities, ExternalImageFormatPropertiesNV, ExternalMemoryHandleTypeFlagsNV, Format, ImageCreateFlags, ImageTiling, ImageType, ImageUsageFlags, PhysicalDevice

Constructors

Instances5Show, Storable, FromCStruct, ToCStruct, Zero

VkExternalMemoryHandleTypeFlagBitsNV - Bitmask specifying external memory handle types

Description

See Also

VK_NV_external_memory_capabilities, ExternalMemoryHandleTypeFlagsNV

Instances8Eq, Ord, Read, Show, Bits, FiniteBits, …

VkExternalMemoryFeatureFlagBitsNV - Bitmask specifying external memory features

Description

See Also

VK_NV_external_memory_capabilities, ExternalImageFormatPropertiesNV, ExternalMemoryFeatureFlagsNV, getPhysicalDeviceExternalImageFormatPropertiesNV

Instances8Eq, Ord, Read, Show, Bits, FiniteBits, …