mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-19 17:48:23 +00:00
56e0289318
* Update release number to 97.
Public Issues:
* Add a special case to the <<renderpass-compatibility, Render Pass
Compatibility>> rules allowing single-subpass renderpasses to be
compatible even if they have different resolve attachment references
(public issue 835).
* Fix the miss shader binding table record address rule in the
<<shader-binding-table-indexing-rules, Miss Shaders>> section to index
by code:missIndex, not code:sbtOffset (public issue 875).
Internal Issues:
* Add a missing anchor to the elink:VkSamplerCreateFlagBits language
(internal issue 1483).
* Add missing implicit valid usage include for slink:VkHdrMetadataEXT and
corresponding `noautovalidity` attributes in `vk.xml` for the
externally-defined metadata properties (internal issue 1514).
* Remove restrictions on the `mask` parameter of SPIR-V's
code:OpGroupNonUniformXor in the <<spirvenv-module-validation,
Validation Rules within a Module>> appendix (internal merge request
2971).
* Restore `noautovalidity` attribute for
slink:VkPipelineViewportWScalingStateCreateInfoNV::pname:pViewportWScalings
in `vk.xml` (internal merge request 2975).
* Update copyright dates on Khronos-copyrighted files to 2019 (internal
merge request 2980).
New Extensions:
* `VK_KHR_depth_stencil_resolve`
* `VK_EXT_buffer_device_address`
* `VK_EXT_memory_budget`
* `VK_EXT_memory_priority`
* `VK_EXT_validation_features`
74 lines
2.2 KiB
Plaintext
74 lines
2.2 KiB
Plaintext
// Copyright (c) 2016-2019 Khronos Group. This work is licensed under a
|
|
// Creative Commons Attribution 4.0 International License; see
|
|
// http://creativecommons.org/licenses/by/4.0/
|
|
|
|
include::meta/VK_KHR_external_memory_fd.txt[]
|
|
|
|
*Last Modified Date*::
|
|
2016-10-21
|
|
*IP Status*::
|
|
No known IP claims.
|
|
*Contributors*::
|
|
- James Jones, NVIDIA
|
|
- Jeff Juliano, NVIDIA
|
|
|
|
An application may wish to reference device memory in multiple Vulkan
|
|
logical devices or instances, in multiple processes, and/or in multiple
|
|
APIs.
|
|
This extension enables an application to export POSIX file descriptor
|
|
handles from Vulkan memory objects and to import Vulkan memory objects from
|
|
POSIX file descriptor handles exported from other Vulkan memory objects or
|
|
from similar resources in other APIs.
|
|
|
|
=== New Object Types
|
|
|
|
None.
|
|
|
|
=== New Enum Constants
|
|
|
|
* ename:VK_STRUCTURE_TYPE_IMPORT_MEMORY_FD_INFO_KHR
|
|
* ename:VK_STRUCTURE_TYPE_MEMORY_FD_PROPERTIES_KHR
|
|
* ename:VK_STRUCTURE_TYPE_MEMORY_GET_FD_INFO_KHR
|
|
|
|
=== New Enums
|
|
|
|
None.
|
|
|
|
=== New Structs
|
|
|
|
* slink:VkImportMemoryFdInfoKHR
|
|
* slink:VkMemoryFdPropertiesKHR
|
|
* slink:VkMemoryGetFdInfoKHR
|
|
|
|
=== New Functions
|
|
|
|
* flink:vkGetMemoryFdKHR
|
|
* flink:vkGetMemoryFdPropertiesKHR
|
|
|
|
=== Issues
|
|
|
|
1) Does the application need to close the file descriptor returned by
|
|
flink:vkGetMemoryFdKHR?
|
|
|
|
*RESOLVED*: Yes, unless it is passed back in to a driver instance to import
|
|
the memory.
|
|
A successful get call transfers ownership of the file descriptor to the
|
|
application, and a successful import transfers it back to the driver.
|
|
Destroying the original memory object will not close the file descriptor or
|
|
remove its reference to the underlying memory resource associated with it.
|
|
|
|
2) Do drivers ever need to expose multiple file descriptors per memory
|
|
object?
|
|
|
|
*RESOLVED*: No.
|
|
This would indicate there are actually multiple memory objects, rather than
|
|
a single memory object.
|
|
|
|
3) How should the valid size and memory type for POSIX file descriptor
|
|
memory handles created outside of Vulkan be specified?
|
|
|
|
*RESOLVED*: The valid memory types are queried directly from the external
|
|
handle.
|
|
The size will be specified by future extensions that introduce such external
|
|
memory handle types.
|