| 1 | |
| 2 |
|
| 3 | ===================================
|
| 4 | drm/amd/display - Display Core (DC)
|
| 5 | ===================================
|
| 6 |
|
| 7 | AMD display engine is partially shared with other operating systems; for this
|
| 8 | reason, 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 | ------------------
|
| 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 | --------------
|
| 76 |
|
| 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:
|
| 80 |
|
| 81 | #. Read frame information from memory;
|
| 82 | #. Perform required transformation;
|
| 83 | #. Send pixel data to sink devices.
|
| 84 |
|
| 85 | If you want to learn more about our driver details, take a look at the below
|
| 86 | table of content:
|
| 87 |
|
| 88 | .. toctree::
|
| 89 |
|
| 90 | display-manager.rst
|
| 91 | dcn-overview.rst
|
| 92 | dcn-blocks.rst
|
| 93 | programming-model-dcn.rst
|
| 94 | mpo-overview.rst
|
| 95 | dc-debug.rst
|
| 96 | display-contributing.rst
|
| 97 | dc-glossary.rst
|