Permalink
Cannot retrieve contributors at this time
| include::meta/VK_NV_external_memory.txt[] | |
| *Last Modified Date*:: | |
| 2016-08-19 | |
| *IP Status*:: | |
| No known IP claims. | |
| *Contributors*:: | |
| - James Jones, NVIDIA | |
| - Carsten Rohde, NVIDIA | |
| Applications may wish to export memory to other Vulkan instances or other | |
| APIs, or import memory from other Vulkan instances or other APIs to enable | |
| Vulkan workloads to be split up across application module, process, or API | |
| boundaries. | |
| This extension enables applications to create exportable Vulkan memory | |
| objects such that the underlying resources can be referenced outside the | |
| Vulkan instance that created them. | |
| === New Object Types | |
| None. | |
| === New Enum Constants | |
| Extending elink:VkStructureType: | |
| ** ename:VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_IMAGE_CREATE_INFO_NV | |
| ** ename:VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_NV | |
| === New Enums | |
| None. | |
| === New Structures | |
| * Extending slink:VkImageCreateInfo: | |
| ** slink:VkExternalMemoryImageCreateInfoNV | |
| * Extending slink:VkMemoryAllocateInfo | |
| ** slink:VkExportMemoryAllocateInfoNV | |
| === New Functions | |
| None. | |
| === Issues | |
| 1) If memory objects are shared between processes and APIs, is this | |
| considered aliasing according to the rules outlined in the | |
| <<resources-memory-aliasing,Memory Aliasing>> section? | |
| *RESOLVED*: Yes, but strict exceptions to the rules are added to allow some | |
| forms of aliasing in these cases. | |
| Further, other extensions may build upon these new aliasing rules to define | |
| specific support usage within Vulkan for imported native memory objects, or | |
| memory objects from other APIs. | |
| 2) Are new image layouts or metadata required to specify image layouts and | |
| layout transitions compatible with non-Vulkan APIs, or with other instances | |
| of the same Vulkan driver? | |
| *RESOLVED*: No. | |
| Separate instances of the same Vulkan driver running on the same GPU should | |
| have identical internal layout semantics, so applictions have the tools they | |
| need to ensure views of images are consistent between the two instances. | |
| Other APIs will fall into two categories: Those that are Vulkan compatible | |
| (a term to be defined by subsequent interopability extensions), or Vulkan | |
| incompatible. | |
| When sharing images with Vulkan incompatible APIs, the Vulkan image must be | |
| transitioned to the ename:VK_IMAGE_LAYOUT_GENERAL layout before handing it | |
| off to the external API. | |
| Note this does not attempt to address cross-device transitions, nor | |
| transitions to engines on the same device which are not visible within the | |
| Vulkan API. | |
| Both of these are beyond the scope of this extension. | |
| === Examples | |
| [source,c++] | |
| ---------------------------------------- | |
| // TODO: Write some sample code here. | |
| ---------------------------------------- | |
| === Version History | |
| * Revision 1, 2016-08-19 (James Jones) | |
| - Initial draft |