mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-28 14:00:27 +00:00
95dd2f34c5
* Bump API patch number and header version number to 28 for this update.
Github Issues:
* Minor spelling and typography cleanup, add definitions of
ename:VK_FALSE and ename:VK_TRUE as just what their names say
(public issues 220, 318, 325, 365; internal issues 451, 496)
* Clarify that the pname:maxDescriptorSet limits in the
<<features-limits-required,Required Limits>> table are n *
maxPerStage limit (where n=number of supported stages) (public issue
254).
* Minor cleanup to <<boilerplate-platform-macros,Platform-Specific
Macro Definitions>> appendix (public issue 314).
* Add valid usage statement to slink:VkPipelineLayoutCreateInfo
disallowing multiple push constant ranges for the same shader stage
(public issue 340).
* Clarify the elink:VkSharingMode description of what executing the
"same" barriers means in case of ownership transfer (public issue
347).
* Rename copyright.txt and add COPYING.md to try and reduce confusion
about applicable copyrights (public issue 350).
* Extend the table in the <<boilerplate-wsi-header, Window System-Specific
Header Control>> section to describe the external headers included when
each etext:VK_USE_PLATFORM_* macro is defined (public issue 376).
Internal Issues:
* Add "Revision History" to the PDF outputs following the table of
contents, to match HTML outputs (internal issue 43).
* Clarified that flink:vkMapMemory may fail due to virtual address
space limitations (internal issue 346).
* Add +refBody+ comment markup for ref page autoextraction when required
(internal issue 400).
* Document proper use of "mipmap" and "mip" in the style guide API
naming rules, matching the spelling rules (internal issue 471).
* Tweak the <<extensions,Layers and Extensions>> appendix to note that
the Specification may be built with arbitrary combinations of
extensions (internal issue 483).
* Remove incorrect statement allowing
slink:VkClearAttachment::pname:colorAttachment to be >=
slink:VkSubpassDescription::pname:colorAttachmentCount (internal
issue 488).
* The <<features-limits-viewportboundsrange,viewportBoundsRange>> is
expressed in terms of the pname:maxViewportDimensions but this is
actually two values. Clarify that it's based on the larger of the two
(if they differ) (internal issue 499).
Other Issues:
* Reflowed text of the entire spec using the 'reflow' Makefile gater,
to (hopefully) reduce future internal git churn as edits are made
and extensions added in return for one-time pain. This has no
perceptible change on the spec outputs but considerable changes on
the asciidoc source (internal issue 367).
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
|