mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-26 04:55:12 +00:00
a5b10770a3
* Update release number to 125.
Github Issues:
* Allow slink:VkRenderPassFragmentDensityMapCreateInfoEXT to extend
slink:VkRenderPassCreateInfo2KHR in `vk.xml` (public issue 1027).
* Fix markup in `<<VK_EXT_external_memory_dma_buf>>` appendix (public pull
request 1051).
* Update .gitignore (public pull request 1052).
Internal Issues:
* Disallowed slink:VkEvent from participating in queue family ownership
transfers in the <<devsandqueues-index, Queue Family Index>> section
(internal issue 1691).
* Relax language describing default NT handle access rights for
slink:VkExportMemoryWin32HandleInfoKHR and
slink:VkExportSemaphoreWin32HandleInfoKHR (internal issue 1838).
* Fix markup for slink:VkDeviceCreateInfo valid usage statement 00372 to
remove imbedded asciidoctor conditionals by splitting it into two VUs
(internal issue 1846).
* Clarify lifetime of samplers used as immutable samplers in
slink:VkDescriptorSetLayoutBinding (internal issue 1849).
* Add a valid usage statement prohibiting flink:vkCmdBeginQuery on
timestamp queries (internal issue 1851).
* Correct some <<Precision of GLSL.std.450 Instructions, SPIR-V
instruction precisions>> (internal merge request 3391).
* Fix a typo in flink:vkQueueBindSparse valid usage statement 03245
(internal merge request 3394).
New Extensions
* `<<VK_KHR_spirv_1_4>>`
55 lines
2.1 KiB
Plaintext
55 lines
2.1 KiB
Plaintext
include::{generated}/meta/VK_EXT_external_memory_dma_buf.txt[]
|
|
|
|
*Last Modified Date*::
|
|
2017-10-10
|
|
*IP Status*::
|
|
No known IP claims.
|
|
*Contributors*::
|
|
- Chad Versace, Google
|
|
- James Jones, NVIDIA
|
|
- Jason Ekstrand, Intel
|
|
|
|
A code:dma_buf is a type of file descriptor, defined by the Linux kernel,
|
|
that allows sharing memory across kernel device drivers and across
|
|
processes.
|
|
This extension enables applications to import a code:dma_buf as
|
|
slink:VkDeviceMemory, to export slink:VkDeviceMemory as a code:dma_buf, and
|
|
to create slink:VkBuffer objects that can: be bound to that memory.
|
|
|
|
=== New Enum Constants
|
|
|
|
* Extending elink:VkExternalMemoryHandleTypeFlagBitsKHR:
|
|
** ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT
|
|
|
|
=== Issues
|
|
|
|
1) How does the application, when creating a slink:VkImage that it intends
|
|
to bind to code:dma_buf slink:VkDeviceMemory containing an externally
|
|
produced image, specify the memory layout (such as row pitch and DRM format
|
|
modifier) of the slink:VkImage? In other words, how does the application
|
|
achieve behavior comparable to that provided by
|
|
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt[`EGL_EXT_image_dma_buf_import`]
|
|
and
|
|
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt[`EGL_EXT_image_dma_buf_import_modifiers`]
|
|
?
|
|
|
|
*RESOLVED*: Features comparable to those in
|
|
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt[`EGL_EXT_image_dma_buf_import`]
|
|
and
|
|
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt[`EGL_EXT_image_dma_buf_import_modifiers`]
|
|
will be provided by an extension layered atop this one.
|
|
|
|
2) Without the ability to specify the memory layout of external code:dma_buf
|
|
images, how is this extension useful?
|
|
|
|
*RESOLVED*: This extension provides exactly one new feature: the ability to
|
|
import/export between code:dma_buf and slink:VkDeviceMemory.
|
|
This feature, together with features provided by
|
|
`<<VK_KHR_external_memory_fd>>`, is sufficient to bind a slink:VkBuffer to
|
|
code:dma_buf.
|
|
|
|
=== Version History
|
|
|
|
* Revision 1, 2017-10-10 (Chad Versace)
|
|
- Squashed internal revisions
|