So here we have it, the end of my Google Summer of Code journey. A few more than a hundred days have passed, and I can already tell that the seeds have been sown for me to keep collaborating with open source software from here on out.
My project’s primary goal was to create unit tests using KUnit for the AMDGPU driver focusing on code used by GPUs from the same generation of the GPU “RX 580” (DCE 11.2). We predicted that KUnit would have some limitations in regards to testing GPU’s drivers, so we expected to see some collaboration in that sense. Finally, we knew that I would be working in parallel with people writing tests for newer generations of GPUs (DCN). I planned to keep track of my weekly progress in my blog, trying to create an introductory material that could help future newcomers.
For starters, this project was completely different from what I had in mind, given that it was far from an individual experience with the Linux Kernel community; it was actually a team effort to introduce unit testing to the AMD display driver in a way that would encourage the community to spread KUnit into other GPU drivers.
Other surprise was how the unit tests didn’t really interact with the GPU, so all our worries about needing to mock devices, and intentions of writing about it, were put aside.
In retrospect, there’s still a lot to learn about the AMD codebase and graphics stack in general, but there are also many things that I’ve learned and didn’t manage to share yet, about IGT, KUnit, and the email-patch workflow, which I’ll be writing in my personal blog in addition to the pair of posts there:
I’ve also dedicated some time reviewing the posts from my colleagues as well, like:
- Isabella’s post about graphics’ stack
- Maíra’s post about symbols
- Magali’s post about rendering test coverage
Introducing Kunit test into AMDGPU
Our patch series is still under review:
We have refactored this series many times before sending it, worrying about how the code should be organized and how the tests should be compiled. My biggest lesson was learning to let go. Do your best to send great patches and reviews to the community, but don’t let the fear of being slightly wrong hold you back from pressing the submit button.
Done is better than perfect!
I didn’t manage to write as many tests as I planned to the DCE11.2 functions, but for what it’s worth, I’m making sure that the KUnit documentation is up to date, so that anyone can write their own tests.
| Patch | Status |
|---|---|
| drm/amd/display: Introduce KUnit tests for fixed31_32 library | Under review |
Contributing to FLOSS projects
In my way to introducing unit tests to the AMD display driver I’ve managed to leave some impressions behind, writing small patches and reviewing code, listed in detail on the following sections.
KWorkflow
Kworflow is a set of bash scripts that helped me to compile and deploy the kernel in my testing system, specially valuable to bisect code. In the beginning of my journey, shortly before the community bounding period, I sent a couple of patches to KWorkflow and reviewed a Pull Request.
| Patch | Status |
|---|---|
| #592 Add support for GPUs identified as “Display controller” in kw device | Accepted |
| #607 Enhance docs for kw-pomodoro and kw-report | Accepted |
- Reviewed #606 Fix large initramfs issue
IGT
IGT GPU Tools is a collection of tools for development and testing of the DRM drivers. One of my first tasks was to run the AMDGPU test suite using the GPU “RX580”. After checking with the community that my testing setup was correct, I reported a bug to the AMD issue tracker, with proper bisection, and followed it through the patching process:
| Patch | Status |
|---|---|
| lib/igt_kmod: fix trivial typos | Under review |
| CONTRIBUTING: Add reference for GTKDoc | Under review |
| lib/kselftests: Skip kselftest when opening kmsg fails | Under review |
| lib/igt_kmod: add igt_kselftests documentation | Under review |
- Reported: “RX 580: igt@amdgpu/amd_cs_nop@fork-compute”
- Tested: Revert “drm/amdgpu: remove ctx->lock”
- Tested: drm/amdgpu: Protect the amdgpu_bo_list list with a mutex v2
- Closed the Issue.
Linux Kernel - KUnit
KUnit is the Kernel Unit Testing Framework. It not only brings a way to facilitate writing tests to the kernel, but also running them using User Mode Linux or QEMU. For most of time in the project we were discussing how to organize tests in the AMD folders, and there were a lot of lessons from that, which I intend to share. I have a lot of documentation patches in their way, some may be worth squashing, but nonetheless, I have the intention to help making the KUnit documentation as clear as possible!
- I started and intend to keep exploring a thread about “running kunit tests on platform devices”. I believe there’s a workaround using one of the approaches we learned while writing tests for AMDGPU.
Linux Kernel - DRM
The Direct Rendering Manager (DRM) is a subsystem of the Linux kernel responsible for interfacing with GPUs. There’s still a lot to learn and contribute to this subsystem, and I hope to discuss about introducing unit tests to other folders during the Linux Plumbers Conference (more about that in a following section). I only have two patches to VKMS to show, sent shortly before the community bounding period.
| Patch | Status |
|---|---|
| drm/vkms: check plane_composer->map[0] before using it | Accepted |
| drm/vkms: return early if compose_plane fails | Discarded |
- Tested: KUnit tests for RGB565 conversion. Following this thread I’ve learned how to run kunit tests for other architectures, like PowerPC.
Linux Kernel - AMDGPU
Inside the DRM subsystem resides the AMD folder, where you can find drivers for many generations of AMD GPUs. Besides our main patch series, I’ve sent some minor patches and reviewed others.
- Reviewed Documentation/amdgpu/display: describe color and blend mode properties mapping
- Reviewed drm/amd/display: remove unreachable code
- Asked for a cherry-pick of two commits from torvalds/master to fix compilation errors on GCC12. The message didn’t receive any replies, but soon after the branch got rebased, fixing the problem.
Acknowledgment
First, I would like to thank the X.org Foundation for accepting my GSoC proposal, for what I’ll be eternally grateful.
Next, thanks to AMD for donating the RX580 GPU which powered my testing system, and alongside Igalia allowed my mentors to take part in the GSoC program.
Moreover I would like to thank The Linux Foundation, which will enable my trip to Dublin, to attend the Linux Plumbers Conference.
There were plenty of great interactions with the DRM community, AMD, and KUnit engineers, for which I’m very thankful, specially David Gow which promptly reviewed most of my team’s patches.
And finally, thanks for my mentors and the other mentees with whom I’ve worked closely this summer, any of this would be possible without their support.
Mentors:
- André “Tony” Almeida (Igalia)
- Melissa Wen (Igalia)
- Rodrigo Siqueira (AMD)
Mentees:
Next steps
Of course this is not farewell! It’s more like reaching the end of a game’s tutorial.
My first step, thanks to The Linux Foundation and my mentors, will be attending in-person the Kernel Testing & Dependability Micro Conference at the Linux Plumber Conference, where I hope to show what we’ve achieved and to discuss about the best way to organize the tests, which is what I’ve invested most of my time, so please keep an eye out for my report about it in my personal blog in the following weeks.
In regards to coding, beyond following through with my patches under review, I intend to write the tests for the DCE functions I proposed initially and maybe extend to other generations, now that we realized that the physical device is not needed in order to write unit tests. I might even look for other modules which would benefit from unit tests, like VKMS.
Finally, I’ll also try to get involved with the KernelCI project, where I could even employ my web development experience. In order to do that I’ll be attending virtually the monthly Automated Testing Call.
Thanks for reading.