drm/v3d 博通 V3D 图形驱动程序

此驱动程序支持博通 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 集成。

从长远来看，我们应该支持在内存压力下从 MMU 中驱逐页面（因此需要 v3d_bo_get_pages() 的引用计数），但由于我们的系统往往没有交换空间，因此这不是一个高优先级。

地址空间管理

与 VC4 相比，V3D 3.x 硬件现在包含一个 MMU。它为 V3D 的 4GB 地址空间到 AXI 总线地址的映射提供了一个单级的页表，因此它可能需要高达 4MB 的物理连续内存来存储 PTE。

由于用于页表的 4MB 连续内存非常宝贵，并且在它们之间切换代价昂贵，我们将所有 BO 加载到相同的 4GB 地址空间中。

为了保护客户端免受彼此的影响，我们应该使用 GMP 快速屏蔽（以 128kb 的粒度）每个客户端可用的页面。这尚未实现。

GPU 调度

共享的 DRM GPU 调度器用于协调向硬件提交作业。每个 DRM fd（大致是一个客户端进程）都有自己的调度器实体，它将按顺序处理作业。GPU 调度器将在客户端之间循环以提交下一个作业。

为了简单起见，并且为了在排队批量后台作业时保持交互作业的低延迟，我们仅在完成上一个作业后才向硬件提交新作业，而不是用作业填充 CT[01]Q FIFO。类似地，我们使用 drm_sched_job_add_dependency() 来管理 bin 和渲染之间的依赖关系，而不是让客户端使用硬件的信号量来提交作业以在它们之间进行互锁。

中断

当我们收到 bin、渲染、TFU 完成或 CSD 完成中断时，我们需要为该作业发出栅栏信号，以便调度器可以排队下一个作业并解除任何等待者的阻塞。

当我们收到 binner 内存不足中断时，我们需要分配一些新内存并将其传递给 binner，以便当前作业可以取得进展。