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. 将像素数据发送到接收设备。

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