]>
Commit | Line | Data |
---|---|---|
ba162ae7 RS |
1 | .. _display_todos: |
2 | ||
3 | ============================== | |
4 | AMDGPU - Display Contributions | |
5 | ============================== | |
6 | ||
7 | First of all, if you are here, you probably want to give some technical | |
8 | contribution to the display code, and for that, we say thank you :) | |
9 | ||
10 | This page summarizes some of the issues you can help with; keep in mind that | |
11 | this is a static page, and it is always a good idea to try to reach developers | |
12 | in the amdgfx or some of the maintainers. Finally, this page follows the DRM | |
13 | way of creating a TODO list; for more information, check | |
14 | 'Documentation/gpu/todo.rst'. | |
15 | ||
16 | Gitlab issues | |
17 | ============= | |
18 | ||
19 | Users can report issues associated with AMD GPUs at: | |
20 | ||
21 | - https://gitlab.freedesktop.org/drm/amd | |
22 | ||
23 | Usually, we try to add a proper label to all new tickets to make it easy to | |
24 | filter issues. If you can reproduce any problem, you could help by adding more | |
25 | information or fixing the issue. | |
26 | ||
27 | Level: diverse | |
28 | ||
29 | IGT | |
30 | === | |
31 | ||
32 | `IGT`_ provides many integration tests that can be run on your GPU. We always | |
33 | want to pass a large set of tests to increase the test coverage in our CI. If | |
34 | you wish to contribute to the display code but are unsure where a good place | |
35 | is, we recommend you run all IGT tests and try to fix any failure you see in | |
36 | your hardware. Keep in mind that this failure can be an IGT problem or a kernel | |
37 | issue; it is necessary to analyze case-by-case. | |
38 | ||
39 | Level: diverse | |
40 | ||
41 | .. _IGT: https://gitlab.freedesktop.org/drm/igt-gpu-tools | |
42 | ||
43 | Compilation | |
44 | =========== | |
45 | ||
46 | Fix compilation warnings | |
47 | ------------------------ | |
48 | ||
49 | Enable the W1 or W2 warning level in the kernel compilation and try to fix the | |
50 | issues on the display side. | |
51 | ||
52 | Level: Starter | |
53 | ||
54 | Fix compilation issues when using um architecture | |
55 | ------------------------------------------------- | |
56 | ||
57 | Linux has a User-mode Linux (UML) feature, and the kernel can be compiled to | |
58 | the **um** architecture. Compiling for **um** can bring multiple advantages | |
59 | from the test perspective. We currently have some compilation issues in this | |
60 | area that we need to fix. | |
61 | ||
62 | Level: Intermediate | |
63 | ||
64 | Code Refactor | |
65 | ============= | |
66 | ||
67 | Add prefix to DC functions to improve the debug with ftrace | |
68 | ----------------------------------------------------------- | |
69 | ||
70 | The Ftrace debug feature (check 'Documentation/trace/ftrace.rst') is a | |
71 | fantastic way to check the code path when developers try to make sense of a | |
72 | bug. Ftrace provides a filter mechanism that can be useful when the developer | |
73 | has some hunch of which part of the code can cause the issue; for this reason, | |
74 | if a set of functions has a proper prefix, it becomes easy to create a good | |
75 | filter. Additionally, prefixes can improve stack trace readability. | |
76 | ||
77 | The DC code does not follow some prefix rules, which makes the Ftrace filter | |
78 | more complicated and reduces the readability of the stack trace. If you want | |
79 | something simple to start contributing to the display, you can make patches for | |
80 | adding prefixes to DC functions. To create those prefixes, use part of the file | |
81 | name as a prefix for all functions in the target file. Check the | |
82 | 'amdgpu_dm_crtc.c` and `amdgpu_dm_plane.c` for some references. However, we | |
83 | strongly advise not to send huge patches changing these prefixes; otherwise, it | |
84 | will be hard to review and test, which can generate second thoughts from | |
85 | maintainers. Try small steps; in case of double, you can ask before you put in | |
86 | effort. We recommend first looking at folders like dceXYZ, dcnXYZ, basics, | |
87 | bios, core, clk_mgr, hwss, resource, and irq. | |
88 | ||
89 | Level: Starter | |
90 | ||
91 | Reduce code duplication | |
92 | ----------------------- | |
93 | ||
94 | AMD has an extensive portfolio with various dGPUs and APUs that amdgpu | |
95 | supports. To maintain the new hardware release cadence, DCE/DCN was designed in | |
96 | a modular design, making the bring-up for new hardware fast. Over the years, | |
97 | amdgpu accumulated some technical debt in the code duplication area. For this | |
98 | task, it would be a good idea to find a tool that can discover code duplication | |
99 | (including patterns) and use it as guidance to reduce duplications. | |
100 | ||
101 | Level: Intermediate | |
102 | ||
103 | Make atomic_commit_[check|tail] more readable | |
104 | --------------------------------------------- | |
105 | ||
106 | The functions responsible for atomic commit and tail are intricate and | |
107 | extensive. In particular `amdgpu_dm_atomic_commit_tail` is a long function and | |
108 | could benefit from being split into smaller helpers. Improvements in this area | |
109 | are more than welcome, but keep in mind that changes in this area will affect | |
110 | all ASICs, meaning that refactoring requires a comprehensive verification; in | |
111 | other words, this effort can take some time for validation. | |
112 | ||
113 | Level: Advanced | |
114 | ||
115 | Documentation | |
116 | ============= | |
117 | ||
118 | Expand kernel-doc | |
119 | ----------------- | |
120 | ||
121 | Many DC functions do not have a proper kernel-doc; understanding a function and | |
122 | adding documentation is a great way to learn more about the amdgpu driver and | |
123 | also leave an outstanding contribution to the entire community. | |
124 | ||
125 | Level: Starter | |
126 | ||
127 | Beyond AMDGPU | |
128 | ============= | |
129 | ||
130 | AMDGPU provides features that are not yet enabled in the userspace. This | |
131 | section highlights some of the coolest display features, which could be enabled | |
132 | with the userspace developer helper. | |
133 | ||
134 | Enable underlay | |
135 | --------------- | |
136 | ||
137 | AMD display has this feature called underlay (which you can read more about at | |
6c6d0cbf | 138 | 'Documentation/gpu/amdgpu/display/mpo-overview.rst') which is intended to |
ba162ae7 RS |
139 | save power when playing a video. The basic idea is to put a video in the |
140 | underlay plane at the bottom and the desktop in the plane above it with a hole | |
141 | in the video area. This feature is enabled in ChromeOS, and from our data | |
142 | measurement, it can save power. | |
143 | ||
144 | Level: Unknown | |
145 | ||
146 | Adaptive Backlight Modulation (ABM) | |
147 | ----------------------------------- | |
148 | ||
149 | ABM is a feature that adjusts the display panel's backlight level and pixel | |
150 | values depending on the displayed image. This power-saving feature can be very | |
151 | useful when the system starts to run off battery; since this will impact the | |
152 | display output fidelity, it would be good if this option was something that | |
153 | users could turn on or off. | |
154 | ||
155 | Level: Unknown | |
156 | ||
157 | ||
158 | HDR & Color management & VRR | |
159 | ---------------------------- | |
160 | ||
161 | HDR, Color Management, and VRR are huge topics and it's hard to put these into | |
162 | concise ToDos. If you are interested in this topic, we recommend checking some | |
163 | blog posts from the community developers to better understand some of the | |
164 | specific challenges and people working on the subject. If anyone wants to work | |
165 | on some particular part, we can try to help with some basic guidance. Finally, | |
166 | keep in mind that we already have some kernel-doc in place for those areas. | |
167 | ||
168 | Level: Unknown |