drm/v3d Broadcom V3D 圖形驅動

該驅動程式支援 Broadcom V3D 3.3 和 4.1 OpenGL ES GPU。 對於 V3D 2.x 支援，請參閱 VC4 驅動程式。

V3D GPU 包括一個分塊渲染器（由 bin 和渲染流水線組成）、TFU（紋理格式化單元）和 CSD（計算著色器排程）。

GPU 緩衝區物件 (BO) 管理

與 VC4 (V3D 2.x) 相比，V3D 3.3 在 GPU 和匯流排之間引入了一個 MMU，允許我們使用 shmem 物件進行儲存，而不是 CMA。

物理上連續的物件仍然可以匯入到 V3D，但驅動程式本身不會分配物理上連續的物件。 需要物理上連續分配的顯示引擎應該研究 Mesa 的“renderonly”支援（如 Mesa pl111 驅動程式所使用），以瞭解如何與 V3D 整合。

地址空間管理

V3D 3.x 硬體（與 VC4 相比）現在包括一個 MMU。 它具有單級頁表，用於將 V3D 的 4GB 地址空間對映到 AXI 匯流排地址，因此它可能需要高達 4MB 的物理連續記憶體來儲存 PTE。

由於用於頁表的 4MB 連續記憶體非常寶貴，並且在它們之間切換成本很高，因此我們將所有 BO 載入到相同的 4GB 地址空間中。

為了保護客戶端免受彼此的影響，我們應該使用 GMP 快速遮蔽（以 128kb 粒度）每個客戶端可用的頁面。 這尚未實現。

GPU 排程

共享的 DRM GPU 排程程式用於協調將作業提交到硬體。 每個 DRM fd（大致是一個客戶端程序）都有自己的排程程式實體，它將按順序處理作業。 GPU 排程程式將使用 FIFO 排程演算法來排程客戶端。

為了簡單起見，並且為了在排隊大量後臺作業時保持互動作業的低延遲，我們僅在完成上一個作業後才向硬體提交新作業，而不是用作業填充 CT[01]Q FIFO。 類似地，我們使用 drm_sched_job_add_dependency() 來管理 bin 和 render 之間的依賴關係，而不是讓客戶端使用硬體的訊號量提交作業以在它們之間進行互鎖。

中斷

當我們接收到 bin、render、TFU 完成或 CSD 完成中斷時，我們需要為該作業發出 fence 訊號，以便排程程式可以排隊下一個作業並解除所有等待者的阻塞。

當我們接收到 binner 記憶體不足中斷時，我們需要分配一些新記憶體並將其傳遞給 binner，以便當前作業可以取得進展。