mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-01-27 14:45:55 +00:00
ef053e7c82
* Bump API patch number and header version number to 27 for this update.
Github Issues:
* Weaken flink:vkGetPipelineCacheData invariance conditions; previous
conditions were stronger than agreed and can't be guaranteed (public
issue 280).
* Add link to "Vulkan Loader Specification and Architecture Overview"
document to Normative References section (public issue 359).
Internal Issues:
* Be more clear in the <<interfaces-resources-layout-std140, uniform
buffer layout>> section that block offsets can be out of order
(internal issue 396).
* Document that extension authors should add support for their extensions
to the validation layers (internal issue 398).
* Clarify that the valid range of depth clear values should be limited
to the 0..1 range and that copies to depth aspect must also be in this
range (internal issue 412).
* Specify ``a'' vs. ``an'' use in the style guide (internal issue 432).
* Increase the maximum pname:nonCoherentAtomSize value in the
<<features-limits-required,Required Limits>> section from 128 to 256
(internal issue 435).
* Fix vk_platform.h for compiler errors on some Android platforms
(internal issue 441).
* Clarify that slink:VkPhysicalDeviceFeatures::pname:pEnabledFeatures ==
`NULL` disables all features, including the "required" feature
pname:robustBufferAccess (internal issue 479).
Other Issues:
* Expand style guide and make it more self-consistent.
* Use ISO 8601 date format everywhere.
* Emphasise the correct way of using
slink:VkSurfaceCapabilitiesKHR::pname:maxImageCount.
* Added +VK_EXT_validation_flags+ extension for validation flag mechanism.
* Fix an <<credits,author credit>> to include their current employer.
105 lines
3.1 KiB
Plaintext
105 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
|