| 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 | on the amd-gfx mailing list or some of the maintainers. Finally, this page
|
| 13 | follows the DRM 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
|