]>
Commit | Line | Data |
---|---|---|
d59f1774 YD |
1 | .. _amdgpu-display-core: |
2 | ||
e91f8401 RS |
3 | =================================== |
4 | drm/amd/display - Display Core (DC) | |
5 | =================================== | |
6 | ||
522968ae RS |
7 | AMD display engine is partially shared with other operating systems; for this |
8 | reason, our Display Core Driver is divided into two pieces: | |
e91f8401 | 9 | |
21dd98b0 | 10 | #. **Display Core (DC)** contains the OS-agnostic components. Things like |
e91f8401 | 11 | hardware programming and resource management are handled here. |
21dd98b0 RS |
12 | #. **Display Manager (DM)** contains the OS-dependent components. Hooks to the |
13 | amdgpu base driver and DRM are implemented here. For example, you can check | |
14 | display/amdgpu_dm/ folder. | |
15 | ||
16 | ------------------ | |
17 | DC Code validation | |
18 | ------------------ | |
19 | ||
20 | Maintaining the same code base across multiple OSes requires a lot of | |
21 | synchronization effort between repositories and exhaustive validation. In the | |
22 | DC case, we maintain a tree to centralize code from different parts. The shared | |
23 | repository has integration tests with our Internal Linux CI farm, and we run a | |
24 | comprehensive set of IGT tests in various AMD GPUs/APUs (mostly recent dGPUs | |
25 | and APUs). Our CI also checks ARM64/32, PPC64/32, and x86_64/32 compilation | |
26 | with DCN enabled and disabled. | |
27 | ||
28 | When we upstream a new feature or some patches, we pack them in a patchset with | |
29 | the prefix **DC Patches for <DATE>**, which is created based on the latest | |
30 | `amd-staging-drm-next <https://gitlab.freedesktop.org/agd5f/linux>`_. All of | |
31 | those patches are under a DC version tested as follows: | |
32 | ||
33 | * Ensure that every patch compiles and the entire series pass our set of IGT | |
34 | test in different hardware. | |
35 | * Prepare a branch with those patches for our validation team. If there is an | |
36 | error, a developer will debug as fast as possible; usually, a simple bisect | |
37 | in the series is enough to point to a bad change, and two possible actions | |
38 | emerge: fix the issue or drop the patch. If it is not an easy fix, the bad | |
39 | patch is dropped. | |
40 | * Finally, developers wait a few days for community feedback before we merge | |
41 | the series. | |
42 | ||
43 | It is good to stress that the test phase is something that we take extremely | |
44 | seriously, and we never merge anything that fails our validation. Follows an | |
45 | overview of our test set: | |
46 | ||
47 | #. Manual test | |
48 | * Multiple Hotplugs with DP and HDMI. | |
49 | * Stress test with multiple display configuration changes via the user interface. | |
50 | * Validate VRR behaviour. | |
51 | * Check PSR. | |
52 | * Validate MPO when playing video. | |
53 | * Test more than two displays connected at the same time. | |
54 | * Check suspend/resume. | |
55 | * Validate FPO. | |
56 | * Check MST. | |
57 | #. Automated test | |
58 | * IGT tests in a farm with GPUs and APUs that support DCN and DCE. | |
59 | * Compilation validation with the latest GCC and Clang from LTS distro. | |
60 | * Cross-compilation for PowerPC 64/32, ARM 64/32, and x86 32. | |
61 | ||
62 | In terms of test setup for CI and manual tests, we usually use: | |
63 | ||
64 | #. The latest Ubuntu LTS. | |
65 | #. In terms of userspace, we only use fully updated open-source components | |
66 | provided by the distribution official package manager. | |
67 | #. Regarding IGT, we use the latest code from the upstream. | |
68 | #. Most of the manual tests are conducted in the GNome but we also use KDE. | |
69 | ||
70 | Notice that someone from our test team will always reply to the cover letter | |
71 | with the test report. | |
72 | ||
73 | -------------- | |
74 | DC Information | |
75 | -------------- | |
e91f8401 | 76 | |
522968ae RS |
77 | The display pipe is responsible for "scanning out" a rendered frame from the |
78 | GPU memory (also called VRAM, FrameBuffer, etc.) to a display. In other words, | |
79 | it would: | |
e91f8401 | 80 | |
21dd98b0 RS |
81 | #. Read frame information from memory; |
82 | #. Perform required transformation; | |
83 | #. Send pixel data to sink devices. | |
e91f8401 | 84 | |
522968ae RS |
85 | If you want to learn more about our driver details, take a look at the below |
86 | table of content: | |
e91f8401 RS |
87 | |
88 | .. toctree:: | |
89 | ||
90 | display-manager.rst | |
522968ae | 91 | dcn-overview.rst |
ee0a54a6 | 92 | dcn-blocks.rst |
6c49df92 | 93 | mpo-overview.rst |
21dd98b0 | 94 | dc-debug.rst |
ba162ae7 | 95 | display-contributing.rst |
a723c6d0 | 96 | dc-glossary.rst |