106 lines
3.0 KiB
Plaintext
106 lines
3.0 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 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 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
|