1.. _amdgpu-display-core: 2 3=================================== 4drm/amd/display - Display Core (DC) 5=================================== 6 7AMD display engine is partially shared with other operating systems; for this 8reason, our Display Core Driver is divided into two pieces: 9 10#. **Display Core (DC)** contains the OS-agnostic components. Things like 11 hardware programming and resource management are handled here. 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------------------ 17DC Code validation 18------------------ 19 20Maintaining the same code base across multiple OSes requires a lot of 21synchronization effort between repositories and exhaustive validation. In the 22DC case, we maintain a tree to centralize code from different parts. The shared 23repository has integration tests with our Internal Linux CI farm, and we run a 24comprehensive set of IGT tests in various AMD GPUs/APUs (mostly recent dGPUs 25and APUs). Our CI also checks ARM64/32, PPC64/32, and x86_64/32 compilation 26with DCN enabled and disabled. 27 28When we upstream a new feature or some patches, we pack them in a patchset with 29the 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 31those 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 43It is good to stress that the test phase is something that we take extremely 44seriously, and we never merge anything that fails our validation. Follows an 45overview 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 62In 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 70Notice that someone from our test team will always reply to the cover letter 71with the test report. 72 73-------------- 74DC Information 75-------------- 76 77The display pipe is responsible for "scanning out" a rendered frame from the 78GPU memory (also called VRAM, FrameBuffer, etc.) to a display. In other words, 79it would: 80 81#. Read frame information from memory; 82#. Perform required transformation; 83#. Send pixel data to sink devices. 84 85If you want to learn more about our driver details, take a look at the below 86table of content: 87 88.. toctree:: 89 90 display-manager.rst 91 dcn-overview.rst 92 dcn-blocks.rst 93 mpo-overview.rst 94 dc-debug.rst 95 display-contributing.rst 96 dc-glossary.rst 97