GSoC 2022 Final Report

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:

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.

drm/amd/display: Introduce KUnit tests for fixed31_32 libraryUnder 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.


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.

#592 Add support for GPUs identified as “Display controller” in kw deviceAccepted
#607 Enhance docs for kw-pomodoro and kw-reportAccepted


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:

lib/igt_kmod: fix trivial typosUnder review
CONTRIBUTING: Add reference for GTKDocUnder review
lib/kselftests: Skip kselftest when opening kmsg failsUnder review
lib/igt_kmod: add igt_kselftests documentationUnder review

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!

Documentation: kunit: fix trivial typoAccepted
Documentation: Kunit: Fix inconsistent titlesAccepted
Documentation: KUnit: Fix non-uml anchorAccepted
Documentation: Kunit: Add ref for other kinds of testsAccepted
Documentation: KUnit: remove duplicated docs for kunit_toolAccepted
Documentation: KUnit: avoid repeating “ run” in start.rstAccepted
Documentation: KUnit: add note about mrproper in start.rstAccepted
Documentation: KUnit: Reword start guide for selecting testsAccepted
Documentation: KUnit: add intro to the getting-started pageAccepted
Documentation: KUnit: update links in the index pageAccepted
lib: overflow: update reference to kunit-toolAccepted
lib: stackinit: update reference to kunit-toolAccepted
kunit: tool: fix –qemu_config help textUnder review

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.

drm/vkms: check plane_composer->map[0] before using itAccepted
drm/vkms: return early if compose_plane failsDiscarded

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.

drm/amd/display: make hubp1_wait_pipe_read_start() staticAccepted
Update AMDGPU glossary and MAINTAINERSAccepted
drm/amd/display: fix overflow on MIN_I64 definitionAccepted
drm/amd/display: fix minor codestyle problemsAccepted
drm/amd/display: remove unneeded defines from bios parserAccepted


First, I would like to thank the 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.



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.