Vulkan-Docs/appendices/VK_EXT_external_memory_dma_buf.txt
Jon Leech f1a7c4b4f3 Change log for January 13, 2019 Vulkan 1.1.98 spec update:
* Update release number to 98.

Public Issues:

  * Fix missing markup in flink:vkDestroyPipelineLayout valid usage
    statement (pull request 882).
  * Add missing contributors for `<<VK_EXT_buffer_device_address>>` (public
    pull request 891).

Internal Issues:

  * Detect nested bullet points in valid usage blocks and warn about them
    during VUID assignment (internal issue 1382).
  * Update the style guide to document the process for reserving new bits in
    bitmask types (internal issue 1411).
  * Clarify for slink:VkApplicationInfo::pname:apiVersion and in the
    <<fundamentals-validusage-versions, Valid Usage for Newer Core
    Versions>> section when it is valid for an application to use a certain
    version of Vulkan API functionality (for an instance and for a
    device/physical device); and when the validation layers must generate an
    error (internal issue 1412).
  * Add optional <<memory-model-availability-visibility, transitive
    availability/visibility operations to the memory model, including a new
    pname:vulkanMemoryModelAvailabilityVisibilityChains feature for
    slink:VkPhysicalDeviceVulkanMemoryModelFeaturesKHR (internal issue
    1460).
  * Add the code:StorageBuffer storage class to those in the
    <<interfaces-resources-descset, Descriptor Set Interface>> (internal
    issue 1480).
  * Add missing `returnedonly` tags for a number of returned extension
    structures that can be passed in pname:pNext chains (internal issue
    1515).
  * Clean up and rearrange some spec language for
    slink:VkRenderPassCreateInfo and slink:VkAttachmentReference.txt
    (internal issue 1522).
  * Correctly round the code:OpVectorTimesScalar and
    code:OpMatrixTimesScalar SPIR-V operations in the <<Precision of core
    SPIR-V Instructions>> table (internal merge request 2996).
  * Work around cases in flink:vkCmdBeginTransformFeedbackEXT,
    flink:vkCmdEndTransformFeedbackEXT, and
    slink:VkPipelineCoverageModulationStateCreateInfoNV where an array
    parameter is `optional` but the length is not in `vk.xml`. This is an
    interim fix using `noautovalidity` + handcoded VU replacing those that
    should be autogenerated (internal issue 2944 and
    https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/480).
  * Remove redundant capability validation of the code:float16 and code:int8
    SPIR-V capabilities from the <<spirvenv-capabilities, Capabilities>>
    section, since they are already covered in the preceding table.
  * Update check_spec_links script, including validation for reference page
    open blocks. Fix errors identified by the script.
2019-01-13 05:53:27 -08:00

61 lines
2.1 KiB
Plaintext

include::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 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 dma_buf as
slink:VkDeviceMemory; to export slink:VkDeviceMemory as a 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 dma_buf slink:VkDeviceMemory that contains 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 dma_buf
images, how is this extension useful?
+
--
*RESOLVED*.
This extension provides exactly one new feature: the ability to
import/export between dma_bufs and slink:VkDeviceMemory.
This feature, together with features provided by
`<<VK_KHR_external_memory_fd>>`, is sufficient to bind a slink:VkBuffer to
dma_buf.
--
=== Version History
* Revision 1, 2017-10-10 (Chad Versace)
- Squashed internal revisions