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，以便当前作业可以取得进展。