107 lines
3.1 KiB
Plaintext
107 lines
3.1 KiB
Plaintext
[[VK_NV_external_memory]]
|
|
== VK_NV_external_memory
|
|
|
|
*Name String*::
|
|
+VK_NV_external_memory+
|
|
*Extension Type*::
|
|
Device extension
|
|
*Registered Extension Number*::
|
|
57
|
|
*Status*::
|
|
Complete
|
|
*Last Modified Date*::
|
|
2016-08-19
|
|
*Revision*::
|
|
1
|
|
*IP Status*::
|
|
No known IP claims.
|
|
*Dependencies*::
|
|
- This extension is written against version 1.0 of the Vulkan API.
|
|
- Requires +VK_NV_external_memory_capabilities+
|
|
*Contributors*::
|
|
- James Jones, NVIDIA
|
|
- Carsten Rohde, NVIDIA
|
|
*Contact*::
|
|
- James Jones (jajones 'at' nvidia.com)
|
|
|
|
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 section 11.8,
|
|
Memory Aliasing?
|
|
|
|
RESOLUTION: 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?
|
|
|
|
RESOLUTION: 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 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,{basebackend@docbook:c++:cpp}]
|
|
----------------------------------------
|
|
|
|
// TODO: Write some sample code here.
|
|
|
|
----------------------------------------
|
|
|
|
=== Version History
|
|
|
|
* Revision 1, 2016-08-19 (James Jones)
|
|
- Initial draft
|