drm/amd/display - 显示核心 (DC)

AMD 显示引擎与其他操作系统部分共享；因此，我们的显示核心驱动程序分为两部分

  1. 显示核心 (DC) 包含与操作系统无关的组件。诸如硬件编程和资源管理之类的操作在此处处理。

  2. 显示管理器 (DM) 包含与操作系统相关的组件。此处实现了与 amdgpu 基础驱动程序和 DRM 的挂钩。例如，您可以检查 display/amdgpu_dm/ 文件夹。

DC 代码验证

在多个操作系统上维护相同的代码库需要在存储库之间进行大量的同步工作以及详尽的验证。在 DC 案例中，我们维护一个树来集中来自不同部分的代码。共享存储库具有与我们的内部 Linux CI 集群的集成测试，并且我们在各种 AMD GPU/APU（主要是最近的 dGPU 和 APU）中运行一套全面的 IGT 测试。我们的 CI 还检查启用和禁用 DCN 的 ARM64/32、PPC64/32 和 x86_64/32 编译。

当我们向上游推送新功能或一些补丁时，我们会将它们打包成一个以 DC Patches for <DATE> 为前缀的补丁集，该补丁集基于最新的 amd-staging-drm-next 创建。所有这些补丁都在 DC 版本下进行如下测试

  • 确保每个补丁都编译通过，并且整个系列在不同的硬件中通过我们的 IGT 测试集。

  • 为我们的验证团队准备一个带有这些补丁的分支。如果出现错误，开发人员将尽快进行调试；通常，该系列中的简单二分就足以指出不良更改，并且会出现两种可能的措施：修复问题或删除补丁。如果不容易修复，则会删除不良补丁。

  • 最后，开发人员会等待几天，以获得社区的反馈，然后再合并该系列。

需要强调的是，测试阶段是我们非常重视的事情，我们绝不会合并任何未通过我们验证的内容。以下是我们的测试集的概述

  1. 手动测试

    • 使用 DP 和 HDMI 进行多次热插拔。

    • 通过用户界面进行多次显示配置更改的压力测试。

    • 验证 VRR 行为。

    • 检查 PSR。

    • 在播放视频时验证 MPO。

    • 测试同时连接的两个以上显示器。

    • 检查挂起/恢复。

    • 验证 FPO。

    • 检查 MST。

  2. 自动测试

    • 在支持 DCN 和 DCE 的 GPU 和 APU 集群中进行 IGT 测试。

    • 使用来自 LTS 发行版的最新 GCC 和 Clang 进行编译验证。

    • PowerPC 64/32、ARM 64/32 和 x86 32 的交叉编译。

在 CI 和手动测试的测试设置方面，我们通常使用

  1. 最新的 Ubuntu LTS。

  2. 在用户空间方面，我们仅使用发行版官方软件包管理器提供的完全更新的开源组件。

  3. 关于 IGT，我们使用来自上游的最新代码。

  4. 大多数手动测试都是在 GNome 中进行的，但我们也使用 KDE。

请注意，我们测试团队的某个人将始终回复带有测试报告的封面信。

DC 信息

显示管道负责将 GPU 内存（也称为 VRAM、FrameBuffer 等）中渲染的帧“扫描输出”到显示器。换句话说，它会

  1. 从内存中读取帧信息；

  2. 执行所需的转换；

  3. 将像素数据发送到接收设备。

如果您想了解更多关于我们驱动程序详细信息的信息，请查看下面的目录