Allow VkImage created from DMA-BUFs to export to compatible handle types [chromium/src : main]
Peng Huang (Gerrit)
Attention is currently required from: Quang Minh Phan, Vasiliy Telezhnikov.
1 comment:
Commit Message:
Patch Set #5, Line 10:
reexportedwhy we need to re-export it? can we just reuse the original fd?
To view, visit change 4689120. To unsubscribe, or for help writing mail filters, visit settings.
Quang Minh Phan (Gerrit)
Attention is currently required from: Peng Huang, Vasiliy Telezhnikov.
1 comment:
Commit Message:
Patch Set #5, Line 10:
reexportedwhy we need to re-export it? can we just reuse the original fd?
`ExternalVkImageBacking` always need to export it as opaque FD for GL interop. Opaque FDs might be implemented as non-DMA-BUF objects on non-Mesa drivers.
To view, visit change 4689120. To unsubscribe, or for help writing mail filters, visit settings.
Vasiliy Telezhnikov (Gerrit)
Attention is currently required from: Peng Huang, Quang Minh Phan.
2 comments:
Commit Message:
Patch Set #5, Line 10:
reexported
`ExternalVkImageBacking` always need to export it as opaque FD for GL interop. […]
Are those dma-bufs are in format that can't be imported using DRI? i.e is it possible to use OzoneImageBacking and import fds both to Vulkan and GL separately, rather than using ExternalVkImage?
File gpu/vulkan/vulkan_image_linux.cc:
Patch Set #6, Line 129:
VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT,Do drivers allow re-export as a different type?
To view, visit change 4689120. To unsubscribe, or for help writing mail filters, visit settings.
Quang Minh Phan (Gerrit)
Attention is currently required from: Peng Huang, Vasiliy Telezhnikov.
2 comments:
Commit Message:
Patch Set #5, Line 10:
reexported
Are those dma-bufs are in format that can't be imported using DRI? i. […]
This is mostly for https://chromium-review.googlesource.com/c/chromium/src/+/4689124/8 where there are other reasons why buffers cannot be imported with `OzoneImageBacking` (e.g. DMA-BUFs imported with `SHARED_IMAGE_USAGE_WEBGPU` on Linux which sometimes happens when using VA-API).
File gpu/vulkan/vulkan_image_linux.cc:
Patch Set #6, Line 129:
VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT,Do drivers allow re-export as a different type?
Yes, as long as it's specified in `VkExportMemoryAllocateInfo` at memory creation time and listed as compatible in `VkExternalMemoryProperties` for the specific image format.
To view, visit change 4689120. To unsubscribe, or for help writing mail filters, visit settings.
Vasiliy Telezhnikov (Gerrit)
Attention is currently required from: Peng Huang, Quang Minh Phan.
1 comment:
Commit Message:
Patch Set #5, Line 10:
reexported
This is mostly for https://chromium-review.googlesource. […]
I think we need to summarize what caps with have and what paths we take and when.
On X11/GL/WithoutSyncFile:
- No GL synchronization possible, but none is needed.
- OzoneImageBacking for VAAPI
- No WebGPU?
On X11/GL/SyncFile:
- No GL synchronization possible, but none is needed.
- OzoneImageBacking for VAAPI
- No WebGPU?
On X11/Vulkan/VANGLE/WithoutSyncFile:
- No EGLSync support in VANGLE
- Vulkan can use OPAQUE_FD
- Vulkan/GL/WebGPU interop works through AngleVulkanImageBacking where it can, falling back to ExternalVkImage and needs to use OPAQUE_FD for fences and images.
- VAAPI also has to go through ExternalVkImage if we need interop with WebGPU.
On X11/Vulkan/VANGLE/SyncFile:
- EGLSync support in VANGLE
- Vulkan can use SYNC_FD
- Everything can work through OzoneImageBacking
On Wayland/GL/WithoutSyncFile:
- Is it possible? If so, how synchronization with compositor works?
On Wayland/GL/SyncFile:
- Should have EGLSync support?
- Vulkan can use SYNC_FD
- Everything can work through OzoneImageBacking
On Wayland/Vulkan/WithoutSyncFile:
- Same here, is it possible?
On Wayland/Vulkan/SyncFile:
- Should have EGLSync support?
- Vulkan can use SYNC_FD
- Everything can work through OzoneImageBacking
Does it sound correct?
To view, visit change 4689120. To unsubscribe, or for help writing mail filters, visit settings.
Quang Minh Phan (Gerrit)
Attention is currently required from: Peng Huang, Vasiliy Telezhnikov.
1 comment:
Commit Message:
Patch Set #5, Line 10:
reexported
Note that in https://chromium-review.googlesource.com/c/chromium/src/+/4689124 WebGPU is assumed to not be using sync files on Linux until we have a way to check what external handle type Dawn is expecting and will give us on image release, so anything WebGPU will fall back to `ExternalVkImageBacking` until Dawn starts using sync_file (and also provide an API to get and set the external semaphore handle type in use). When that happens, WebGPU will be able to use `OzoneImageBacking`.
On Wayland/GL/WithoutSyncFile:
- Is it possible? If so, how synchronization with compositor works?
Through implicit synchronization (at least on Linux) although this isn't yet supported in https://chromium-review.googlesource.com/c/chromium/src/+/4689124.
On Wayland/Vulkan/WithoutSyncFile:
- Same here, is it possible?
This is simply unsupported.
Otherwise everything else should be correct.
To view, visit change 4689120. To unsubscribe, or for help writing mail filters, visit settings.
Vasiliy Telezhnikov (Gerrit)
Attention is currently required from: Peng Huang, Quang Minh Phan.
1 comment:
Commit Message:
Patch Set #5, Line 10:
reexported
Note that in https://chromium-review.googlesource. […]
Thanks for confirming. I'm just summarizing for me (and anyone who will dig this thread) the rationale why and what we're doing:
So we have two "problematic" cases:
* X11/Vulkan/VANGLE/WithoutSyncFile where we have to use ExternalVkImage for WebGPU (We can't use VulkanAngleImageBacking as it runs on a separate device).
For cases when we just create SI itself (e.g webgpu back buffers), this currently works.
But if we have external dma-buf (e.g from VAAPI), we can import it to Vulkan, but can't import it to GL using external memory extensions (needs OPAQUE_FD). And don't have means of synchronization outside of external semaphores.
So we have two options here:
* Use ExternalVkImage and that requires re-export of the VulkanImages with different flags. This is done in this CL.
* Use OzoneImageBacking without synchronization (VAAPI doesn't need one anyway). This might be tricky, because we don't know where dma bufs come from.On Wayland/GL/WithoutSyncFile:
- We have to use OzoneImageBacking (so we can send buffers to compositor), but we have to ignore all synchronization and rely on implicit sync?
- This means no WebGPU too.
I'm not opposed to approach in this CL, but it seems we need to keep a way for OzoneImageBacking to not do any sync for `Wayland/GL/WithoutSyncFile`.
To view, visit change 4689120. To unsubscribe, or for help writing mail filters, visit settings.
Quang Minh Phan (Gerrit)
Attention is currently required from: Peng Huang, Vasiliy Telezhnikov.
1 comment:
Commit Message:
Patch Set #5, Line 10:
reexported
Thanks for confirming. […]
https://chromium-review.googlesource.com/c/chromium/src/+/4689124/13..14 can now handle Wayland/GL/WithoutSyncFile cases.
To view, visit change 4689120. To unsubscribe, or for help writing mail filters, visit settings.
Vasiliy Telezhnikov (Gerrit)
Attention is currently required from: Peng Huang, Quang Minh Phan.
Patch set 11:Code-Review +1
1 comment:
Patchset:
Sorry for taking too long. lgtm, thanks for working on it.
To view, visit change 4689120. To unsubscribe, or for help writing mail filters, visit settings.
Peng Huang (Gerrit)
Attention is currently required from: Quang Minh Phan.
To view, visit change 4689120. To unsubscribe, or for help writing mail filters, visit settings.
Quang Minh Phan (Gerrit)
Attention is currently required from: Quang Minh Phan.
Patch set 12:Commit-Queue +2
Chromium LUCI CQ (Gerrit)
Chromium LUCI CQ submitted this change.
11 is the latest approved patch-set.
No files were changed between the latest approved patch-set and the submitted one.
Allow VkImage created from DMA-BUFs to export to compatible handle types
This allows VkImages imported from native pixmaps on Linux (e.g. VA-API)
to be reexported to external memory FDs, which is needed by
ExternalVkImageBacking.
Bug: 1411745
Change-Id: I26ceb5f1e3a68d4a423a28785b3d4f8f065b1a93
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4689120
Reviewed-by: Peng Huang <peng...@chromium.org>
Commit-Queue: Quang Minh Phan <phanquan...@gmail.com>
Reviewed-by: Vasiliy Telezhnikov <vas...@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1175880}
---
M gpu/vulkan/vulkan_image_linux.cc
1 file changed, 16 insertions(+), 0 deletions(-)
diff --git a/gpu/vulkan/vulkan_image_linux.cc b/gpu/vulkan/vulkan_image_linux.cc
index 4a3ecfe..6c744ca 100644
--- a/gpu/vulkan/vulkan_image_linux.cc
+++ b/gpu/vulkan/vulkan_image_linux.cc
@@ -10,6 +10,7 @@
#include "base/logging.h"
#include "gpu/vulkan/vulkan_device_queue.h"
#include "gpu/vulkan/vulkan_function_pointers.h"
+#include "gpu/vulkan/vulkan_util.h"
namespace {
@@ -119,6 +120,21 @@
.fd = memory_fd,
};
+ VkExportMemoryAllocateInfo export_memory_info = {
+ VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_KHR};
+ VkExternalMemoryProperties external_memory_properties;
+ VkResult vk_result = QueryVkExternalMemoryProperties(
+ device_queue->GetVulkanPhysicalDevice(), format, VK_IMAGE_TYPE_2D,
+ image_tiling, usage, flags,
+ VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT,
+ &external_memory_properties);
+ if (vk_result == VK_SUCCESS) {
+ export_memory_info.handleTypes =
+ external_memory_properties.compatibleHandleTypes;
+
+ import_memory_fd_info.pNext = &export_memory_info;
+ }
+
VkMemoryRequirements* requirements = nullptr;
// TODO support multiple plane
bool result = InitializeSingleOrJointPlanes(
To view, visit change 4689120. To unsubscribe, or for help writing mail filters, visit settings.