使用者空間中的 DMA-BUF

memfd

若 A、B 同屬一程序，即它們共享記憶體地址空間，其實只需將 A 的影象資料地址傳遞給 B 並保證 A、B 不同時使用此資料，與其複製不如共享同一塊儲存區域。

但如果 A、B 是兩個不同的程序呢？這就需要檔案作為中介。

memfd 是由核心建立的以記憶體為後端的匿名檔案（FD），並可以使用 mmap 對映到當前程序的虛擬地址空間來對檔案進行讀寫。因此透過在 A、B 之間傳遞引用影象資料的 memfd 即可實現資料零複製共享。

exporter.c
c
#define _GNU_SOURCE
#include <errno.h>
#include <stdio.h>
#include <sys/mman.h>
#include <unistd.h>
#define LEN 1024
int main(void) {
  int fd = memfd_create("image", 0);
  ftruncate(fd, LEN);
  void *data = mmap(NULL, LEN, PROT_WRITE, MAP_SHARED, fd, 0);
  // 寫入字串資料
  sprintf(data, "Hello World!\n");
  printf("/proc/%d/fd/%d\n", getpid(), fd);
  pause();
  return 0;
}

importer.c
c
#define _GNU_SOURCE
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#define LEN 1024
int main(int argc, char *argv[]) {
  int fd = open(argv[1], O_RDWR);
  void *data = mmap(NULL, LEN, PROT_READ, MAP_SHARED, fd, 0);
  // 輸出字串資料
  printf("%s", (char *)data);
  return 0;
}

shell
$ gcc -o exporter exporter.c && ./exporter
/proc/123456/fd/3

shell
$ gcc -o importer importer.c
$ ./importer /proc/123456/fd/3
Hello World!

DMA-BUF FD

在使用者空間，DMA-BUF 的形式就是 FD，故而它和 memfd 有相似的屬性，它也可以和其他 FD 一樣被傳遞，取決於實現也可能執行 mmap 操作。

不過有一點最大的不同就是 DMA-BUF 不能被使用者建立，它是核心模組對儲存區域的抽象引用，而你只能透過核心模組提供的 ioctl 介面或檔案介面等匯出、匯入 DMA-BUF FD。

通常只有 DRM 模組、V4L2 模組等圖形相關核心模組會提供 DMA-BUF 匯出或匯入介面以滿足高效能零複製傳遞影象資料需求。使用者可將模組 A 匯出的 DMA-BUF FD 匯入至模組 B 或是模組 A 自身，使用者在此過程中扮演的角色只是路由。

而對於 DMA-BUF 在核心空間的儲存後端和傳遞則是對使用者是不透明的，它的儲存可以位於視訊記憶體、可以位於記憶體、也可以位於硬體獨有儲存，資料的傳遞也不一定透過 DMA 而可以透過 CPU。

DRM format modifier

在 Vulkan 和 OpenGL 等圖形應用中，你通常不會使用核心提供介面而是廠商實現的圖形 API 進行 DMA-BUF 操作，故除了純粹的匯出、匯入外，你還會獲取或需要提供如畫素格式、尺寸等圖形相關的元資訊。

而 DRM format modifier 是更底層的描述 DMA-BUF 資料的畫素結構的 64-bit 整數描述符。

對於一張影象畫素在記憶體中的排列，最自然的有線性排列，即按順序排放從第一行到最後一行的資料，資料可按 x + y * 列寬 定址。這種線性排列就可以用 DRM_FORMAT_MOD_LINEAR（0x0）描述。

而如 Intel、AMD 等廠商通常會有私有定義的或許效能更佳的畫素排列，這時他們會選擇一個新的 64-bit 整數作為此排列的描述符以區分其他排列。

而其他私有但不需要區分的排列通常會使用 DRM_FORMAT_MOD_INVALID 描述。

通常只有 DRM_FORMAT_MOD_LINEAR 格式描述的資料可以被使用者直接解析使用，而其他格式的資料只能被使用者中轉匯出匯入。

Vulkan

在 Vulkan 中，如果驅動實現支援 VK_EXT_external_memory_dma_buf 擴充套件，則使用者可以利用它匯入和匯出 DMA-BUF FD。

而利用 VK_EXT_image_drm_format_modifier 則可進行對特定影象格式所支援的 DRM format modifier 進行查詢，以便在匯入 DMA-BUF FD 時使用正確格式。

OpenGL

OpenGL 是平臺無關的，但 OpenGL 上下文的建立是平臺相關的，這就需要中間曾的介入以建立上下文、視窗、實現影象儲存後端，對於 X11 有 GLX，對於 Wayland 有 EGL，對於 Windows 有 WGL。

其中 EGL 類似 Vulkan 以擴充套件的方式提供 X11、Wayland 等平臺的支援。

而 EGL 提供了 EGL_EXT_image_dma_buf_import 和 EGL_EXT_image_dma_buf_export 擴充套件以供驅動實現 DMA-BUF FD 匯入匯出支援。

桌面環境

在 KDE、GNOME 等 Wayland 桌面實現中，DMA-BUF 被用於螢幕/視窗共享，其中最通行的即是桌面環境實現 XDG Desktop Portal，而使用者程式呼叫其中的螢幕共享介面 org.freedesktop.portal.ScreenCast 以獲取螢幕/視窗資料的 DMA-BUF FD。

PipeWire

PipeWire 是影片和音訊資料的交換中心，其中的影片資料就支援依賴 DRM format modifier 的 DMA-BUF 共享機制。

XDG Desktop Portal 的螢幕共享介面和攝像頭介面其實就是以 PipeWire 為後端的。

VA-API

VA-API 是硬體影片編解碼加速 API，它可選的支援使用 DMA-BUF 作為編碼輸入。故而對於螢幕錄製可以先將螢幕匯出為 DMA-BUF FD 再匯入編碼以減少傳輸損失。

GStreamer

GStreamer 支援 DMA-BUF 作為影片儲存格式（video/x-raw(memory:DMABuf)），故只要外掛支援 DMABuf 就可以使用 DMA-BUF。比如使用 pipewiresrc 和 glimagesink 實現 EGL/OpenGL 零複製顯示 PipeWire 中支援 DMA-BUF 的影片源，又或是配合 VA-API 外掛進行高效能錄製編碼。