GSoC Project Idea: Introduce Unit Tests to the AMDGPU Component
Mentor: Rodrigo Siqueira (aka, Siqueira)
Co-mentor: Melissa Wen
Pre-requisites
For this project, all GSoC contributors must:
- have any Linux-based distro as their main system
- feel comfortable with the terminal and working with the Linux command-line
- have a moderate knowledge of C (e.g. working with pointers should not be an issue)
- be willing to participate on a public mailing list
- be able to work in a group and be willing to help other people
- fully complete the warm-up and first patch sections
Warm-up
This section is mandatory for everybody
If you are interested in this project, you must complete the following pre-requisites before you start your application:
- setup a virtual machine - https://flusp.ime.usp.br/others/use-qemu-to-play-with-linux/
- learn how to compile the Linux kernel - https://flusp.ime.usp.br/others/Kernel-compilation-and-installation/
- learn how to install and remove a Linux kernel - https://flusp.ime.usp.br/others/Kernel-compilation-and-installation/
- learn how to deal with modules - https://flusp.ime.usp.br/others/play_with_modules/
- learn how to use kw to speed-up your workflow - https://kworkflow.org/ and try to deploy a new kernel by using this tool (see the tutorial section)
- learn the basics about the Linux kernel contribution process; we recommend you to at least carefully read the following pages:
- as a freedesktop.org project, dri-devel and the DRM community follow the Contributor Covenant, found at: https://www.freedesktop.org/wiki/CodeOfConduct
- subscribe to the dri-devel mailing-list and join the oftc#dri-devel channel on IRC
If you are not able to complete these steps, or did not have fun doing them, this project may not be a good fit for you.
First Patch
This section is mandatory for everybody
Now it is time for you to send your first set of contributions; for this part, you should send a single patch and a patchset (minimum of two patches in the patchset). You are free to send any patch to any kernel subsystem that you prefer; however, to increase your chance to get feedback and your change merged, we recommend the following:
For your first contribution, we recommend something simple but useful. For this reason, here is a list of potential contributions in order of importance:
Compile your kernel with
W=1
, capture all kernel logs in a file, and try to fix them (try to make a real fix, not simply silencing the compilation warning).Compile the kernel documentation, take a look at all warnings and errors and try to fix some of them.
Run
kw codestyle
and try to fix some of the issues. If you try this type of contribution, do not improve things blindly. Find a problem, understand it, evaluate if we really need it, and then make your patch. Please, try to be very critical of yourself if you try this type of contribution because many of the complaints generated by the kernel codestyle are ignored for a reason.
Since Siqueira is one of the maintainers of the display code from the amdgpu driver, we recommend you use the AMD repository: https://gitlab.freedesktop.org/agd5f/linux/-/tree/amd-staging-drm-next. Again, this is not mandatory, but this will increase your chances of getting a review and your change merged.
You can focus on any part of the kernel that you want, but we recommend you to work on
drivers/gpu/drm/amd/display/
since we will work on these drivers during the GSoC project.
Project Idea
Our goal is to explore KUnit in a production driver context. KUnit is a lightweight unit testing and mocking framework for the Linux kernel.
In this project, contributors will introduce some basic unit test to an AMD display component called the Display Mode Library (DML) which is a library that computes display parameters to be set in the hardware. Aside from the unit test, we need to enable some level of integration with IGT GPU Test Tools and, if possible, find a way to generate a code coverage report. For writing your project proposal, we recommend you to read the following links to learn more about this topic:
https://www.kernel.org/doc/html/v5.9/dev-tools/kunit/index.html
Basic documentation about DRM API and Display Core. We do not expect that the contributor will fully understand these pages; we just want you to have an overall idea in order to write your project proposal.
https://www.kernel.org/doc/html/latest/gpu/drm-kms.html?highlight=kms
https://www.kernel.org/doc/html/latest/gpu/amdgpu/display/dcn-overview.html
How To Prepare Your Project Proposal
The warm-up section is mandatory for everyone; for this reason, your final project proposal should have one section per assignment with two or three paragraphs that describe your experience with each task. Additionally, including screenshots demonstrating that you've completed those activities (e.g. showing your VM running with your custom kernel) is a plus.
Finally, make sure that you have the following sections in your application:
Basic info about you (Name, preferred pronouns, GitLab or similar, your blog page, your website, email, and IRC nickname);
One or two paragraphs about you;
A section that describes how you achieved each of the warm-up pre-requisites;
Sections that describe your interaction with the Linux kernel (your first patches);
Add a section that describes your understanding of the project. We recommend you include something about KUnit and the AMD display core.
A section that breaks down how you plan to execute the project proposal while following the GSoC timeline. As previously mentioned, the project's primary goal is to introduce KUnit tests to the DML component of AMD display drivers. Project proposals outside of this context will not be accepted. Although the scope of this project is well defined, contributors need to demonstrate they also understand their skills and boundaries. Therefore, contributors should build a project proposal based on their knowledge, acquired skills, as well as their own ideas. Besides that, they should propose an executive plan with tasks that fit the GSoC milestones. Please, make sure to add two main milestones (i.e. it should match the GSoC evaluation dates).
NOTE: Feel free to share your draft before submitting the final version. We'll be happy to give you feedback to improve and strengthen your proposal.