| // Copyright (c) 2016-2020 NVIDIA Corporation |
| // |
| // SPDX-License-Identifier: CC-BY-4.0 |
| |
| include::{generated}/meta/{refprefix}VK_NV_external_memory_capabilities.txt[] |
| |
| === 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 `apiext:VK_KHR_dedicated_allocation`. |
| - Interacts with `apiext: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. |
| |
| include::{generated}/interfaces/VK_NV_external_memory_capabilities.txt[] |
| |
| === 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 slink: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 flink: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 |
