|
| 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 |
| 138 | +'Documentation/GPU/amdgpu/display/mpo-overview.rst') which is intended to |
| 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 |
0 commit comments