My journey on the Google Summer of Code project passed by so fast… This is my last week on the GSoC and those 14 weeks flew by! A lot of stuff happened during those three months, and as I’m writing this blog post, I feel quite nostalgic about this three months.

Before I started GSoC, I never thought I would send so many patches to the mailing list, have an abstract approved on XDC 2022, or have commit rights on drm-misc.

GSoC was indeed a fantastic experience. It gave me the opportunity to grow as a developer in an open source community and I believe that I ended up GSoC with a better understanding of what open source is. I learned more about the community, how to communicate with them, and who are the actors in this workflow.

So, this is a summary report of all my journey at GSoC 2022.

Contributions during GSoC 2022

First I will kick off with my non-related contributions. I mean, they are somehow related to my project, but they are not exactly unit tests for AMDGPU.

kworkflow

kworkflow is a tool for reducing the environment and setup overhead of developing for Linux, which is maintained by my mentor Rodrigo Siqueira. I use it to manage my config files, deploy to my testing machine, check code style, and more. Initially, kw didn’t have support to deploy for Fedora-based machines.

During the Community Bonding Period, I added support to deploy Fedora-based machines and I wrote a bit about this story in this blog post. Moreover, I fixed a couple of bugs that I spotted while using it.

IGT

IGT GPU Tools is a collection of tools for the development and testing of DRM drivers. During GSoC, I ran the AMDGPU suite a couple of times on my testing machine with a single display connected through HDMI. With this setup, I was able to detect a couple of failures on the IGT tests and I reported some of those issues on the AMD bug tracker, but also I sent two patches fixing a couple of failures on the test.

Linux Kernel - KUnit

KUnit is the Kernel Unit Testing Framework. It is the framework we used for creating unit tests for the AMDGPU drivers. My patches to KUnit are based on problems that I noticed I could improve while I was writing unit tests for VBA. First, I fixed a simple documentation error I spotted when I consulted the docs. The other patches are a bit more interesting.

While I was writing some tests, I realize I was using a lot of expectations such as:

KUNIT_EXPECT_EQ(test, memcmp(buffer1, buffer2, size), 0);

And I also realize that the output of this expectation can be quite non-helpful, as it only gives the output of the memcmp function. So, I created an expectation macro for analyzing blocks of memory and outputs the hexdump of the memory.

It was a great community experience to interact with the KUnit developers and work on their feedback.

Linux Kernel - DRM

In the DRM subsystem, I contributed to the DRM unit tests, which used to be selftests and I converted them to KUnit during an LKCamp hackathon with other students. I explained more about those tests in this blog post. After those patches were merged, I dedicated myself to some janitorial duties on the tests folders: fixing stack warnings, refactoring some tests, and making the naming more consistent.

Also, this summer, I applied for commit rights on the drm-misc repository and it was approved. I got pretty glad to have commit rights, although I believe it is such a huge responsibility and I plan to use this right very carefully. I must thank my mentor Melissa Wen for encouraging me to ask for commit rights and for sharing her knowledge about the community and maintainership models (and also for answering a thousand questions I had about dim).

Linux Kernel - AMDGPU

Most of my patches to the AMDGPU branch were ideas that I had while writing the unit tests on VBA. The display_mode_vba files were automatically generated, which means that the code might not be the most readable one. During the summer, I had a couple of ideas for cleaning up a bit of the VBA files and some of those ideas are documented in this blog post. And most of my patches are related to this matter.

But, most of the patches I sent related to the VBA files weren’t merged and there was also no feedback on the patches. Some were sent multiple times, but I didn’t get an answer. The DML is a very sensitive part of the AMDGPU driver, so big changes might not be suitable for them.

Moreover, there are a couple of fixes. My favorite one is the drm/amdgpu: Fix use-after-free on amdgpu_bo_list mutex, which was a fix to a use-after-free problem that appeared in the mailing list. It was fun to read the output provided in the mailing-list and then track the bug based on the trace. Also, it was a really nice interaction with other developers on the mailing list.

The KUnit AMDGPU Tests

After this huge tangent, let’s jump into the real milestones of the GSoC project. Making a small recapitulation of the idea of my project:

The Display Mode Library (DML) is a fundamental part of the AMDGPU driver. It involves lots of complex calculations and a large number of parameters. That said, it points to itself as a great candidate for the implementation of unit tests. Unit tests will help graphic developers recognize bugs before they are merged into the mainline and make it possible for a future code refactor. This project intends to implement unit testing in the Display Mode VBA libraries, especially the Display Mode VBA public API and the DCN20’s Display Mode VBA functions.

In my project, the deliverables were:

• Eleven unit tests for all the public functions on display_mode_vba and display_mode_vba20.
• Five blog posts on the progress, problems, concepts, and all.
• Run the unit tests on the AMDGPU Radeon RX 5700 XT.
• Write documentation for the tests.

So, let’s discuss point by point the milestones of this summer.

The Unit Tests and Documentation

First, I had the intention to write unit tests for all the public functions on display_mode_vba and display_mode_vba20, which are eleven functions in total. Initially, it seems like a good idea to test only the public functions, which is usually recommended by Software Engineering authors.

I started following this plan, but as I was learning more about unit testing, I started questioning the feasibility of tests for some functions. I mean, a couple of functions had more than 45 input parameters and more than a thousand lines. Checking all the possible code branches of those tests seemed to me unfeasible because there were a lot of variables to be considered.

As the function size and the number of parameters grow, the complexity of the tests grows exponentially.

So, I ended up writing tests for some static VBA functions. In the end, I wrote more than eleven unit tests but the functions for which they were written are not the same as planned initially.

The functions were chosen by two means. First, I was trying to identify functions with a more suitable behavior for unit tests. Basically, functions with no more than 10 parameters and 100 lines. Also, I was looking for functions that were used a lot in the code, in order to increase the coverage and the relevance of the tests. But also, sometimes, Siqueira would suggest some functions outside of VBA, such as the dc_dmub_srv case, which was inspired on a regression.

Moreover, I also wrote documentation for the tests, giving instructions on how to run the tests and how to add more tests to the AMDGPU driver.

The patches with the test suites and documentation are listed here:

The tests are not merged yet and are currently on the second version, but there are some good changes that the tests will be merged soon to the mainline.

Moreover, I was able to run all the unit tests developed on the AMDGPU Radeon RX 5700 XT, and also with the kunit-tool.

The Blog Posts

During the summer, I wrote five blog posts about challenges that I found interesting in my journey. All blog posts are listed here:

More than just code

During this summer, I was able to evolve my community skills also. Before I joined GSoC, I didn’t though I had enough knowledge to review code from others or even read the mailing list. Now, I have more confidence to review and test some patches (and even commit a patch).

During GSoC, I developed the habit to read the mailing list daily. Although I don’t really get everything that is going on there, I read a couple of threads and try to understand what is being discussed. And it became a fun part of my day to open Thunderbird and read the mailing lists from AMDGPU, DRM, KUnit, and Fedora Devel.

Moreover, during my mailing list readings, I was able to find some discussions that I could contribute to and even review patches. Initially, I didn’t have confidence enough to send a Reviewed-by, so I used to send just a Tested-by. But, now I feel more courage to send a Reviewed-by and make an argument for my points on the mailing lists.

I made more than a dozen interactions on the mailing list, so I will just list the more relevant ones:

1. My first Tested-by: This was after some interaction with David Gow on the AMDGPU Unit Tests RFC. I stated the need for enabling tests to link to the AMDGPU module and this culminated in some patches for it, where I sent my Tested-by. Also this discussion was the inspiration for this blog post.
2. Documentation Reviews on KUnit: I reviewed a couple of KUnit documentation patches, such as 1 and 2.
3. Spot an error in an IGT patch: This is a simple one, but it make me realize that I was about to help with my reviews.
4. Reported a failing KUnit test: I was checking LKFT some day, and I realized that some KUnit tests were failing in all architectures. So, I sent an email reporting the failure to the tests’s author and he fixed the tests.
5. PowerPC Compilation Fixes: On the same day I sent a patch fixing a PowerPC warning on the DRM tests, Melissa asked me how I cross-compiled for PPC on IRC as she was working on a PPC warning. I was happy I could help her with this after some hours of failing to cross-compile for PPC. This resulted in other review and also a great interaction.

Moreover, I also committed two patches on drm-misc-next. I reviewed to patches for improving the DRM KUnit tests and by the end of the review, I usually wait for someone to push the patches into drm-misc-next, but as those patches were on the list for a while, I decided to push it myself. I was pretty afraid of doing something wrong, but all went fine with a bit of help from Melissa.

Next Steps

Well, I’m pretty excited about the next couple of months for many reasons. First, I, Magali Lemes, and Isabella Basso will be attending XDC 2022. It is going to be very exciting to participate in an in-place conference and also to make a presentation on the main track.

We are going to talk about the “KUnit sorcery and the uncanny nature of FPU in the DRM” on October 4th, presenting a bit of our GSoC project. So, currently, I’m training a lot to make a good presentation in October.

Moreover, I intend to keep contributing to the DRM subsystem, and currently, I have some ideas for some code refactors of the DRM KUnit tests. Also, I would like to expand my contributions on the DRM to not only test-related. Although I do like to write unit tests, I want to learn more about planes, CRTC, color management, memory management, and more. Currently, most of my contributions are related to janitorial duties and I would like to contribute to implementing new features on the DRM or improving the DRM core.

Finally, by the end of GSoC, I’ll be joining another mentorship project on the Linux Graphics Stack, which is making me very excited to continue to work with open source, especially the kernel.

Acknowledgment

First, I would like to thank my mentors Rodrigo Siqueira, Melissa Wen, and André Almeida. They really believed in our potential, encouraged us to talk to the community, and show us some great opportunities. They were an amazing team of mentors and I will always be thankful to them. Without them, I would probably never would had submitted a project to GSoC.

Also, I would like to thank the X.Org Foundation for accepting my proposal to GSoC and also helping us with funding for XDC 2022.

Moreover, I would like to thank AMD for donating hardware for us. During the project, I used a Radeon RX 5700 XT donated by them, so I’m also very thankful to them. Moreover, I would like to thank all AMD engineers that took their time to review my patches and send feedback.

Finally, I would like to thank the DRI community for reviewing my patches and giving me constructive feedback. Also, the KUnit community, especially David Gow, Daniel Latypov, and Brendan Higgins, review a lot of my patches and took their time to meet with us this summer.

Last, but not least, I thank the companionship of my colleagues Isabella Basso, Magali Lemes, and Tales Aparecida during this summer. It was great to have some companions to solve problems this summer and to share knowledge.