drm/amd/display - Display Core (DC)

Display Core와 Display Manager

AMD display engine code 일부는 여러 operating system이 공유합니다. 그래서 Display Core driver는 OS-agnostic한 Display Core(DC)와 Linux/DRM 의존적인 Display Manager(DM)의 두 부분으로 나뉩니다.

.. _amdgpu-display-core:

===================================
drm/amd/display - Display Core (DC)
===================================

AMD display engine is partially shared with other operating systems; for this
reason, our Display Core Driver is divided into two pieces:

#. **Display Core (DC)** contains the OS-agnostic components. Things like
   hardware programming and resource management are handled here.
#. **Display Manager (DM)** contains the OS-dependent components. Hooks to the
   amdgpu base driver and DRM are implemented here. For example, you can check
   display/amdgpu_dm/ folder.

DC patchset의 validation gate

여러 OS에서 같은 code base를 유지하려면 repository 사이의 synchronization과 폭넓은 validation이 필요합니다. DC는 여러 출처의 code를 중앙화하는 tree를 유지하고 Internal Linux CI farm의 integration test와 다양한 AMD GPU/APU의 IGT test를 실행합니다. 대상은 주로 최근 dGPU와 APU입니다.

Compilation CI는 DCN enabled와 disabled 구성을 모두 사용하며 ARM64/32, PPC64/32, x86_64/32를 확인합니다. 이는 feature code가 특정 architecture, word size 또는 DCN configuration만 우연히 통과하는 것을 막기 위한 gate입니다.

새 feature 또는 patch는 최신 `amd-staging-drm-next <https://gitlab.freedesktop.org/agd5f/linux>`를 기준으로 만들고 `DC Patches for <DATE>` prefix의 patchset으로 묶습니다. 모든 patch는 하나의 검증된 DC version 아래에서 다룹니다.

------------------
DC Code validation
------------------

Maintaining the same code base across multiple OSes requires a lot of
synchronization effort between repositories and exhaustive validation. In the
DC case, we maintain a tree to centralize code from different parts. The shared
repository has integration tests with our Internal Linux CI farm, and we run a
comprehensive set of IGT tests in various AMD GPUs/APUs (mostly recent dGPUs
and APUs). Our CI also checks ARM64/32, PPC64/32, and x86_64/32 compilation
with DCN enabled and disabled.

When we upstream a new feature or some patches, we pack them in a patchset with
the prefix **DC Patches for <DATE>**, which is created based on the latest
`amd-staging-drm-next <https://gitlab.freedesktop.org/agd5f/linux>`_. All of
those patches are under a DC version tested as follows:

* Ensure that every patch compiles and the entire series pass our set of IGT
  test in different hardware.
* Prepare a branch with those patches for our validation team. If there is an
  error, a developer will debug as fast as possible; usually, a simple bisect
  in the series is enough to point to a bad change, and two possible actions
  emerge: fix the issue or drop the patch. If it is not an easy fix, the bad
  patch is dropped.
* Finally, developers wait a few days for community feedback before we merge
  the series.

It is good to stress that the test phase is something that we take extremely
seriously, and we never merge anything that fails our validation. Follows an
overview of our test set:

수동·자동 test와 실행 환경

DC team은 validation에 실패한 change를 merge하지 않는다고 명시합니다. 수동 test는 connector event, 여러 display topology, power transition과 display feature를 실제 UI 및 playback scenario에서 확인합니다.

Test team 담당자는 patchset cover letter에 항상 test report를 reply합니다. 따라서 merge 판단에는 code review뿐 아니라 해당 report의 hardware와 test 결과도 포함됩니다.

#. Manual test
    * Multiple Hotplugs with DP and HDMI.
    * Stress test with multiple display configuration changes via the user interface.
    * Validate VRR behaviour.
    * Check PSR.
    * Validate MPO when playing video.
    * Test more than two displays connected at the same time.
    * Check suspend/resume.
    * Validate FPO.
    * Check MST.
#. Automated test
    * IGT tests in a farm with GPUs and APUs that support DCN and DCE.
    * Compilation validation with the latest GCC and Clang from LTS distro.
    * Cross-compilation for PowerPC 64/32, ARM 64/32, and x86 32.

In terms of test setup for CI and manual tests, we usually use:

#. The latest Ubuntu LTS.
#. In terms of userspace, we only use fully updated open-source components
   provided by the distribution official package manager.
#. Regarding IGT, we use the latest code from the upstream.
#. Most of the manual tests are conducted in the GNome but we also use KDE.

Notice that someone from our test team will always reply to the cover letter
with the test report.

Display pipe와 scanout

Display pipe는 GPU memory에 rendering된 frame을 display로 scanout하는 경로입니다. GPU memory는 문맥에 따라 VRAM 또는 FrameBuffer라고도 부릅니다.

--------------
DC Information
--------------

The display pipe is responsible for "scanning out" a rendered frame from the
GPU memory (also called VRAM, FrameBuffer, etc.) to a display. In other words,
it would:

#. Read frame information from memory;
#. Perform required transformation;
#. Send pixel data to sink devices.

If you want to learn more about our driver details, take a look at the below
table of content:

Display Core 하위 문서 탐색

Toctree는 Display Core 문서를 다음 여덟 항목 순서로 연결합니다. RST file 이름과 순서는 navigation 및 link audit를 위해 그대로 보존합니다.

.. toctree::

   display-manager.rst
   dcn-overview.rst
   dcn-blocks.rst
   programming-model-dcn.rst
   mpo-overview.rst
   dc-debug.rst
   display-contributing.rst
   dc-glossary.rst