요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. _display_todos:
==============================
AMDGPU - Display Contributions
==============================
First of all, if you are here, you probably want to give some technical
contribution to the display code, and for that, we say thank you :)
This page summarizes some of the issues you can help with; keep in mind that
this is a static page, and it is always a good idea to try to reach developers
on the amd-gfx mailing list or some of the maintainers. Finally, this page
follows the DRM way of creating a TODO list; for more information, check
'Documentation/gpu/todo.rst'.
Gitlab issues
=============
Users can report issues associated with AMD GPUs at:
- https://gitlab.freedesktop.org/drm/amd
Usually, we try to add a proper label to all new tickets to make it easy to
filter issues. If you can reproduce any problem, you could help by adding more
information or fixing the issue.
Level: diverse
IGT
===
`IGT`_ provides many integration tests that can be run on your GPU. We always
want to pass a large set of tests to increase the test coverage in our CI. If
you wish to contribute to the display code but are unsure where a good place
is, we recommend you run all IGT tests and try to fix any failure you see in
your hardware. Keep in mind that this failure can be an IGT problem or a kernel
issue; it is necessary to analyze case-by-case.
Level: diverse
.. _IGT: https://gitlab.freedesktop.org/drm/igt-gpu-tools
Compilation
===========
Fix compilation warnings
------------------------
Enable the W1 or W2 warning level in the kernel compilation and try to fix the
issues on the display side.
Level: Starter
Fix compilation issues when using um architecture
-------------------------------------------------
Linux has a User-mode Linux (UML) feature, and the kernel can be compiled to
the **um** architecture. Compiling for **um** can bring multiple advantages
from the test perspective. We currently have some compilation issues in this
area that we need to fix.
Level: Intermediate
Code Refactor
=============
Add prefix to DC functions to improve the debug with ftrace
-----------------------------------------------------------
The Ftrace debug feature (check 'Documentation/trace/ftrace.rst') is a
fantastic way to check the code path when developers try to make sense of a
bug. Ftrace provides a filter mechanism that can be useful when the developer
has some hunch of which part of the code can cause the issue; for this reason,
if a set of functions has a proper prefix, it becomes easy to create a good
filter. Additionally, prefixes can improve stack trace readability.
The DC code does not follow some prefix rules, which makes the Ftrace filter
more complicated and reduces the readability of the stack trace. If you want
something simple to start contributing to the display, you can make patches for
adding prefixes to DC functions. To create those prefixes, use part of the file
name as a prefix for all functions in the target file. Check the
'amdgpu_dm_crtc.c` and `amdgpu_dm_plane.c` for some references. However, we
strongly advise not to send huge patches changing these prefixes; otherwise, it
will be hard to review and test, which can generate second thoughts from
maintainers. Try small steps; in case of double, you can ask before you put in
effort. We recommend first looking at folders like dceXYZ, dcnXYZ, basics,
bios, core, clk_mgr, hwss, resource, and irq.
Level: Starter
Reduce code duplication
-----------------------
AMD has an extensive portfolio with various dGPUs and APUs that amdgpu
supports. To maintain the new hardware release cadence, DCE/DCN was designed in
a modular design, making the bring-up for new hardware fast. Over the years,
amdgpu accumulated some technical debt in the code duplication area. For this
task, it would be a good idea to find a tool that can discover code duplication
(including patterns) and use it as guidance to reduce duplications.
Level: Intermediate
Make atomic_commit_[check|tail] more readable
---------------------------------------------
The functions responsible for atomic commit and tail are intricate and
extensive. In particular `amdgpu_dm_atomic_commit_tail` is a long function and
could benefit from being split into smaller helpers. Improvements in this area
are more than welcome, but keep in mind that changes in this area will affect
all ASICs, meaning that refactoring requires a comprehensive verification; in
other words, this effort can take some time for validation.
Level: Advanced
Documentation
=============
Expand kernel-doc
-----------------
Many DC functions do not have a proper kernel-doc; understanding a function and
adding documentation is a great way to learn more about the amdgpu driver and
also leave an outstanding contribution to the entire community.
Level: Starter
Beyond AMDGPU
=============
AMDGPU provides features that are not yet enabled in the userspace. This
section highlights some of the coolest display features, which could be enabled
with the userspace developer helper.
Enable underlay
---------------
AMD display has this feature called underlay (which you can read more about at
'Documentation/gpu/amdgpu/display/mpo-overview.rst') which is intended to
save power when playing a video. The basic idea is to put a video in the
underlay plane at the bottom and the desktop in the plane above it with a hole
in the video area. This feature is enabled in ChromeOS, and from our data
measurement, it can save power.
Level: Unknown
Adaptive Backlight Modulation (ABM)
-----------------------------------
ABM is a feature that adjusts the display panel's backlight level and pixel
values depending on the displayed image. This power-saving feature can be very
useful when the system starts to run off battery; since this will impact the
display output fidelity, it would be good if this option was something that
users could turn on or off.
Level: Unknown
HDR & Color management & VRR
----------------------------
HDR, Color Management, and VRR are huge topics and it's hard to put these into
concise ToDos. If you are interested in this topic, we recommend checking some
blog posts from the community developers to better understand some of the
specific challenges and people working on the subject. If anyone wants to work
on some particular part, we can try to help with some basic guidance. Finally,
keep in mind that we already have some kernel-doc in place for those areas.
Level: Unknown
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
기여 시작점: issue와 IGT
1-42이 페이지는 AMDGPU display code에 기술적으로 기여하려는 사람을 위한 정적 TODO 목록입니다. 목록은 시간이 지나면 실제 우선순위와 달라질 수 있으므로 작업을 시작하기 전에 amd-gfx mailing list 또는 maintainer에게 문의하는 것이 좋습니다. 구성 방식은 DRM TODO 문서인 `Documentation/gpu/todo.rst`를 따릅니다.
정적 TODO를 바로 구현 목록으로 간주하지 않고 현재 상태를 먼저 확인합니다.
AMD GPU 관련 issue는 `https://gitlab.freedesktop.org/drm/amd`에서 보고할 수 있습니다. 새 ticket에는 적절한 label을 붙여 filtering을 돕습니다. 이미 재현 가능한 문제라면 추가 hardware·log·재현 정보를 보태거나 직접 수정하는 것도 중요한 기여입니다. 이 항목의 Level은 `diverse`로, issue마다 난이도가 다릅니다.
`IGT`는 GPU에서 실행하는 다양한 integration test를 제공합니다. CI test coverage를 넓히려면 큰 test set의 통과율을 높여야 합니다. 어디서 시작할지 모른다면 자신의 hardware에서 전체 IGT suite를 실행하고 failure 하나를 분석하는 방법이 권장됩니다. 다만 failure는 IGT test 자체의 문제일 수도, kernel의 문제일 수도 있으므로 case-by-case 분석이 필요합니다.
두 시작점 모두 재현과 원인 분리가 핵심입니다.
통과하지 못했다는 사실만으로 kernel regression이라고 단정하지 않습니다.
.. _display_todos:
==============================
AMDGPU - Display Contributions
==============================
First of all, if you are here, you probably want to give some technical
contribution to the display code, and for that, we say thank you :)
This page summarizes some of the issues you can help with; keep in mind that
this is a static page, and it is always a good idea to try to reach developers
on the amd-gfx mailing list or some of the maintainers. Finally, this page
follows the DRM way of creating a TODO list; for more information, check
'Documentation/gpu/todo.rst'.
Gitlab issues
=============
Users can report issues associated with AMD GPUs at:
- https://gitlab.freedesktop.org/drm/amd
Usually, we try to add a proper label to all new tickets to make it easy to
filter issues. If you can reproduce any problem, you could help by adding more
information or fixing the issue.
Level: diverse
IGT
===
`IGT`_ provides many integration tests that can be run on your GPU. We always
want to pass a large set of tests to increase the test coverage in our CI. If
you wish to contribute to the display code but are unsure where a good place
is, we recommend you run all IGT tests and try to fix any failure you see in
your hardware. Keep in mind that this failure can be an IGT problem or a kernel
issue; it is necessary to analyze case-by-case.
Level: diverse
.. _IGT: https://gitlab.freedesktop.org/drm/igt-gpu-tools
Compilation warning과 UML
43-63첫 compilation 과제는 kernel build에서 W1 또는 W2 warning level을 enable하고 display 쪽 warning을 수정하는 것입니다. 기능 동작을 바꾸지 않고 compiler가 지적하는 type, declaration, format 문제를 정리할 수 있어 Level은 `Starter`입니다.
두 번째 과제는 User-mode Linux(UML)의 `um` architecture로 kernel을 compile할 때 발생하는 display 관련 build issue를 고치는 것입니다. UML build는 실제 GPU 없이도 여러 test 관점의 이점을 주지만 architecture assumption과 stub dependency를 이해해야 하므로 Level은 `Intermediate`입니다.
원문은 특정 build command를 제시하지 않으므로 사용하는 tree의 build guide와 configuration을 함께 확인합니다.
단일 warning 제거가 다른 configuration을 깨지 않는지 확인합니다.
Compilation
===========
Fix compilation warnings
------------------------
Enable the W1 or W2 warning level in the kernel compilation and try to fix the
issues on the display side.
Level: Starter
Fix compilation issues when using um architecture
-------------------------------------------------
Linux has a User-mode Linux (UML) feature, and the kernel can be compiled to
the **um** architecture. Compiling for **um** can bring multiple advantages
from the test perspective. We currently have some compilation issues in this
area that we need to fix.
Level: Intermediate
DC code refactor 과제와 검증 범위
64-114Ftrace는 `Documentation/trace/ftrace.rst`에 설명된 code-path 조사 도구입니다. Function prefix가 일관되면 filter를 쉽게 만들고 stack trace도 읽기 좋아집니다. DC code에는 prefix rule을 따르지 않는 함수가 있어 filtering과 trace 해석을 어렵게 합니다.
Starter 기여로 target file 이름 일부를 prefix로 사용해 그 파일의 함수 이름을 정리할 수 있습니다. 참고 file은 `amdgpu_dm_crtc.c`와 `amdgpu_dm_plane.c`입니다. 하지만 prefix를 한 번에 대규모로 바꾸면 review와 test가 어려워지고 maintainer가 patch 자체를 꺼릴 수 있으므로 작은 단위로 나누고, 확신이 없으면 작업 전에 질문해야 합니다.
원문이 먼저 살펴보도록 권장한 directory 이름을 그대로 보존했습니다.
Rename 범위를 좁혀 review 가능성과 bisect 가능성을 높입니다.
AMDGPU는 다양한 dGPU와 APU를 지원합니다. 빠른 hardware bring-up을 위해 DCE/DCN은 modular design으로 만들어졌지만, 세대가 늘면서 유사 code와 pattern이 중복되는 technical debt가 축적되었습니다. Code duplication과 유사 pattern을 찾는 tool을 조사 지침으로 사용해 공통화 후보를 찾는 과제의 Level은 `Intermediate`입니다.
`atomic_commit_[check|tail]` 경로는 복잡하고 길며, 특히 `amdgpu_dm_atomic_commit_tail`은 작은 helper로 나눌 여지가 있습니다. 그러나 이 경로는 모든 ASIC에 영향을 주므로 단순 readability patch처럼 보여도 comprehensive verification이 필요합니다. Validation 시간이 길 수 있는 `Advanced` 과제입니다.
변경 줄 수보다 hardware와 call-path 영향 범위가 검증 난이도를 결정합니다.
Code Refactor
=============
Add prefix to DC functions to improve the debug with ftrace
-----------------------------------------------------------
The Ftrace debug feature (check 'Documentation/trace/ftrace.rst') is a
fantastic way to check the code path when developers try to make sense of a
bug. Ftrace provides a filter mechanism that can be useful when the developer
has some hunch of which part of the code can cause the issue; for this reason,
if a set of functions has a proper prefix, it becomes easy to create a good
filter. Additionally, prefixes can improve stack trace readability.
The DC code does not follow some prefix rules, which makes the Ftrace filter
more complicated and reduces the readability of the stack trace. If you want
something simple to start contributing to the display, you can make patches for
adding prefixes to DC functions. To create those prefixes, use part of the file
name as a prefix for all functions in the target file. Check the
'amdgpu_dm_crtc.c` and `amdgpu_dm_plane.c` for some references. However, we
strongly advise not to send huge patches changing these prefixes; otherwise, it
will be hard to review and test, which can generate second thoughts from
maintainers. Try small steps; in case of double, you can ask before you put in
effort. We recommend first looking at folders like dceXYZ, dcnXYZ, basics,
bios, core, clk_mgr, hwss, resource, and irq.
Level: Starter
Reduce code duplication
-----------------------
AMD has an extensive portfolio with various dGPUs and APUs that amdgpu
supports. To maintain the new hardware release cadence, DCE/DCN was designed in
a modular design, making the bring-up for new hardware fast. Over the years,
amdgpu accumulated some technical debt in the code duplication area. For this
task, it would be a good idea to find a tool that can discover code duplication
(including patterns) and use it as guidance to reduce duplications.
Level: Intermediate
Make atomic_commit_[check|tail] more readable
---------------------------------------------
The functions responsible for atomic commit and tail are intricate and
extensive. In particular `amdgpu_dm_atomic_commit_tail` is a long function and
could benefit from being split into smaller helpers. Improvements in this area
are more than welcome, but keep in mind that changes in this area will affect
all ASICs, meaning that refactoring requires a comprehensive verification; in
other words, this effort can take some time for validation.
Level: Advanced
Kernel-doc 확장
115-126많은 DC 함수에는 적절한 kernel-doc가 없습니다. 함수의 caller, parameter, return value, state transition을 이해한 뒤 문서를 추가하는 작업은 AMDGPU driver를 학습하면서 community 전체에 오래 남는 설명을 제공하는 좋은 Starter 기여입니다.
주석 형식만 채우는 것이 아니라 실제 contract를 source에서 확인합니다.
Documentation
=============
Expand kernel-doc
-----------------
Many DC functions do not have a proper kernel-doc; understanding a function and
adding documentation is a great way to learn more about the amdgpu driver and
also leave an outstanding contribution to the entire community.
Level: Starter
Userspace가 활성화할 Underlay와 ABM
127-156AMDGPU에는 kernel 또는 hardware 쪽 기능은 존재하지만 일반 userspace에서 아직 활성화되지 않은 display feature가 있습니다. 이 영역은 kernel change만으로 끝나지 않고 compositor, browser, desktop policy 같은 userspace 개발자의 협력이 필요합니다.
Underlay는 `Documentation/gpu/amdgpu/display/mpo-overview.rst`에 설명된 power-saving 기능입니다. Video를 아래 underlay plane에 놓고, 그 위 desktop plane은 video 영역에 구멍을 둡니다. ChromeOS에서는 활성화되어 있으며 원문이 언급한 측정에서는 video playback 전력을 줄일 수 있습니다. 일반 userspace 활성화 과제의 Level은 `Unknown`입니다.
Video를 desktop 아래에 배치해 효율적인 scanout을 노립니다.
Adaptive Backlight Modulation(ABM)은 표시 image에 따라 panel backlight level과 pixel value를 함께 조정하는 power-saving 기능입니다. Battery 동작 시 유용하지만 display output fidelity에 영향을 주므로 userspace가 user에게 on/off 선택을 제공하는 것이 바람직합니다. 이 과제도 Level은 `Unknown`입니다.
자동 절전 효과와 사용자의 화질 선택권을 함께 다뤄야 합니다.
두 기능 모두 userspace integration과 정책 결정이 남아 있습니다.
Beyond AMDGPU
=============
AMDGPU provides features that are not yet enabled in the userspace. This
section highlights some of the coolest display features, which could be enabled
with the userspace developer helper.
Enable underlay
---------------
AMD display has this feature called underlay (which you can read more about at
'Documentation/gpu/amdgpu/display/mpo-overview.rst') which is intended to
save power when playing a video. The basic idea is to put a video in the
underlay plane at the bottom and the desktop in the plane above it with a hole
in the video area. This feature is enabled in ChromeOS, and from our data
measurement, it can save power.
Level: Unknown
Adaptive Backlight Modulation (ABM)
-----------------------------------
ABM is a feature that adjusts the display panel's backlight level and pixel
values depending on the displayed image. This power-saving feature can be very
useful when the system starts to run off battery; since this will impact the
display output fidelity, it would be good if this option was something that
users could turn on or off.
Level: Unknown
HDR, Color Management와 VRR
157-168HDR, Color Management, VRR은 각각 큰 기술 영역이라 간단한 TODO 몇 개로 축약하기 어렵습니다. 관심 있는 contributor는 community developer의 blog post를 통해 구체적인 challenge와 현재 작업자를 먼저 파악하는 것이 권장됩니다.
특정 하위 영역을 정하면 AMD display developer가 기본 방향을 안내할 수 있으며, 이미 이 영역에 kernel-doc도 일부 존재합니다. 과제 범위가 정해져 있지 않아 Level은 `Unknown`입니다.
모두 kernel capability, userspace policy와 hardware 검증이 만나는 영역입니다.
구체적인 하위 문제로 좁힌 뒤 현재 담당자와 맞춥니다.
HDR & Color management & VRR
----------------------------
HDR, Color Management, and VRR are huge topics and it's hard to put these into
concise ToDos. If you are interested in this topic, we recommend checking some
blog posts from the community developers to better understand some of the
specific challenges and people working on the subject. If anyone wants to work
on some particular part, we can try to help with some basic guidance. Finally,
keep in mind that we already have some kernel-doc in place for those areas.
Level: Unknown
요약·해설
display-contributing.rst:1-168AMDGPU display에 기여할 수 있는 issue triage, IGT, compilation, refactor, kernel-doc와 userspace feature 과제를 난이도와 검증 범위별로 정리한 전문 번역입니다. 정적 목록이므로 실제 착수 전 amd-gfx와 maintainer 확인이 필요합니다.
원문 11개 Level 항목을 빠르게 비교합니다.