mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-25 12:35:11 +00:00
* Update release number to 124. Github Issues: * Fix Makefile SPECREMARK macro to work when not building in a git tree (public issue 992). * Ignore pname:aspectMask for unused attachments in slink:VkSubpassDescription2KHR valid usage statements (public pull request 1028). * Minor markup / spelling fixes (public pull requests 1035, 1045). Internal Issues: * Fix markup in Valid Usage statement for slink:VkCreateFramebuffer (internal issue 1823). * Add a new <<synchronization-signal-operation-order, _signal operation order_>> section to the synchronization chapter which describes in detail the ordering guarantees provided by the API between fence and semaphore signal operations (internal merge request 3368). * Move generated `appendix/meta/` files into the Makefile GENERATED directory (internal merge request 3381). New Extensions * `<<VK_KHR_shader_clock>>` * `<<VK_KHR_timeline_semaphore>>`
79 lines
2.3 KiB
Plaintext
79 lines
2.3 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::{generated}/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.
|
|
|
|
=== Version History
|
|
|
|
* Revision 1, 2016-10-21 (James Jones)
|
|
- Initial revision
|