Loading...
Searching...
No Matches
VulkanRhiContext.hpp File Reference

Acquire the raw Vulkan handles (instance/physDev/device/queue/family) behind a Vulkan QRhi, for the RDMA GPU-direct interop paths. More...

Detailed Description

Acquire the raw Vulkan handles (instance/physDev/device/queue/family) behind a Vulkan QRhi, for the RDMA GPU-direct interop paths.

The RDMA Vulkan capture + output shims all need the same handles out of QRhiVulkanNativeHandles + score's shared QVulkanInstance to drive the exportable-image / CUDA-import machinery, so the acquisition lives here rather than once per shim.

This is the common denominator of the AJA and Deltacast Vulkan RDMA paths. Their transfer machinery does not converge – AJA uses per-slot LINEAR images imported as flat CUDA buffers (cuda_interop copy dtod-2d) with an exportable-VkBuffer bounce pinned via DMABufferLock, while Deltacast uses a single OPTIMAL image imported as a CUDA array (cuda_interop copy buffer<->array) backed by RdmaGpuBuffer. These are deliberate, correctness-driven choices (AJA notes an OPTIMAL-image-as-array "scrambles per-tile on this driver"), so a shared transfer base is a redesign, not a mechanical move.

Go to the source code of this file.