|
| 1 | +// Copyright 2022-2025 The Khronos Group Inc. |
| 2 | +// SPDX-License-Identifier: CC-BY-4.0 |
| 3 | + |
| 4 | +# VK_MESA_legacy_dma_buf_drm_format_modifier_query |
| 5 | +:toc: left |
| 6 | +:docs: https://docs.vulkan.org/spec/latest/ |
| 7 | +:extensions: {docs}appendices/extensions.html# |
| 8 | +:sectnums: |
| 9 | + |
| 10 | +This document proposes adding support for querying the implicit DRM format |
| 11 | +modifier from a legacy dma-buf. |
| 12 | + |
| 13 | +## Problem Statement |
| 14 | + |
| 15 | +Buffer sharing within the Linux graphics stack has a long history. |
| 16 | +Before we had DRM format modifiers, individual DRM drivers often had ways |
| 17 | +of attaching a small amount of tiling information to a dma-buf. |
| 18 | +Selecting an image tiling was done by convention and the tiling information |
| 19 | +was passed side-band in a vendor-specific way, assuming all drivers in the |
| 20 | +system would know what to do with it. |
| 21 | +This method of handling tiled images was severely limiting and has since |
| 22 | +been replaced by DRM format modifiers which allows for explicit |
| 23 | +communication of tiling information and negotiation of image tiling between |
| 24 | +components. |
| 25 | + |
| 26 | +Unfortunately, some legacy components such as the X server still use |
| 27 | +implicit image tiling. |
| 28 | +This extension provides a way to import these legacy dma-buf images into |
| 29 | +Vulkan. |
| 30 | +For example, this allows Zink (an OpenGL implementation on top of Vulkan) |
| 31 | +to properly implement `glXBindTexImageEXT()`, even if the image comes from |
| 32 | +an OpenGL driver which assumes the legacy tiling conventions. |
| 33 | + |
| 34 | +## Proposal |
| 35 | + |
| 36 | +### Dependencies |
| 37 | + |
| 38 | + - VK_KHR_external_memory_fd |
| 39 | + |
| 40 | +### API Features |
| 41 | + |
| 42 | +The following features are exposed by this extension: |
| 43 | + |
| 44 | +[source,c] |
| 45 | +---- |
| 46 | +typedef struct VkPhysicalDeviceLegacyDmaBufDrmFormatModifierQueryFeaturesEXT { |
| 47 | + VkStructureType sType; |
| 48 | + void* pNext; |
| 49 | + VkBool32 legacyDmaBufDrmFormatModifierQuery; |
| 50 | +} VkPhysicalDeviceLegacyDmaBufDrmFormatModifierQueryFeaturesEXT; |
| 51 | +---- |
| 52 | + |
| 53 | + . `legacyDmaBufDrmFormatModifierQuery` indicates support for querying |
| 54 | + DRM format modifiers from legacy dma-bufs. |
| 55 | + |
| 56 | +The DRM format modifier associated with a legacy dma-buf may be queried by |
| 57 | +adding a `VkMemoryFdLegacyDmaBufDrmFormatModifierPropertiesMESA` struct to |
| 58 | +the `pNext` chain of `VkMemoryFdPropertiesKHR`. |
| 59 | + |
| 60 | +---- |
| 61 | +typedef struct VkMemoryFdLegacyDmaBufDrmFormatModifierPropertiesMESA { |
| 62 | + VkStructureType sType; |
| 63 | + void* pNext; |
| 64 | + uint64_t drmFormatModifier; |
| 65 | +} VkMemoryFdLegacyDmaBufDrmFormatModifierPropertiesMESA; |
| 66 | +---- |
| 67 | + |
| 68 | +The returned modifier may then be passed into `vkCreateImage()` via |
| 69 | +`VkImageDrmFormatModifierExplicitCreateInfoEXT` and used to create a |
| 70 | +`VkImage` which is bound to the dma-buf at offset 0. |
| 71 | + |
| 72 | +Unfortunately, due to the history of dma-buf, there is no way to tell the |
| 73 | +difference between a dma-buf which has been created using the modifiers |
| 74 | +protocol and a legacy dma-buf. |
| 75 | +This query may return the wrong modifier in that case. |
| 76 | +The legacy dma-buf format modifier query should only ever be used in the |
| 77 | +case where the client knows that the dma-buf image has been created via |
| 78 | +legacy paths and not modifiers. |
| 79 | + |
| 80 | +## Issues |
| 81 | + |
| 82 | +None. |
0 commit comments