{ Maíra Canal }

GSoC Final Report

Date:

Tags: #gsoc #kernel

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.

Patch Status
docs: dependencies: Add pv to Fedora dependencies Accepted
src: kwlib: check if the context is inside a git worktree Accepted
Add deploy support to Fedora-based systems Accepted
src: help: Fix renaming of configm to kernel-config-manager Accepted

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.

Patch Status
[i-g-t,v2] tests/amdgpu: Skip multihead MPO tests on single display Accepted
[i-g-t,v2] tests/amdgpu/amd_bypass: skip if connector is not DisplayPort On Review

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.

Patch Status
Documentation: KUnit: Fix example with compilation error Accepted
kunit: Introduce KUNIT_EXPECT_MEMEQ and KUNIT_EXPECT_MEMNEQ macros Accepted
kunit: Add KUnit memory block assertions to the example_all_expect_macros_test Accepted
kunit: Use KUNIT_EXPECT_MEMEQ macro Accepted

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).

Patch Status
drm: selftest: convert drm_damage_helper selftest to KUnit Accepted
drm: selftest: convert drm_cmdline_parser selftest to KUnit Accepted
drm: selftest: convert drm_rect selftest to KUnit Accepted
drm: selftest: convert drm_format selftest to KUnit Accepted
drm: selftest: convert drm_plane_helper selftest to KUnit Accepted
drm: selftest: convert drm_dp_mst_helper selftest to KUnit Accepted
drm: selftest: convert drm_framebuffer selftest to KUnit Accepted
drm: selftest: convert drm_buddy selftest to KUnit Accepted
drm: selftest: convert drm_mm selftest to KUnit Accepted
drm/tests: Split up test cases in igt_check_drm_format_min_pitch Accepted
drm/mm: Reduce stack frame usage in __igt_reserve On Review
drm/tests: Split drm_framebuffer_create_test into parameterized tests On Review
drm/tests: Change “igt_” prefix to “test_drm_” On Review

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.

Patch Status
drm/amd/display: Remove return value of Calculate256BBlockSizes Accepted
drm/amd/display: Remove duplicate code across dcn30 and dcn31 Accepted
drm/amd/display: Remove unused variables from vba_vars_st Accepted
drm/amdgpu: Write masked value to control register Accepted
drm/amd/display: Change get_pipe_idx function scope Accepted
drm/amd/display: Remove unused clk_src variable Accepted
drm/amd/display: Remove unused dml32_CalculatedoublePipeDPPCLKAndSCLThroughput function Accepted
drm/amd/display: Remove unused NumberOfStates variable Accepted
drm/amd/display: Remove unused variables from dml_rq_dlg_get_dlg_params Accepted
drm/amd/display: Remove unused value0 variable On Review
drm/amd/display: Remove unused variables from dcn10_stream_encoder Accepted
drm/amd/display: Remove unused MaxUsedBW variable Accepted
drm/amd/display: Remove parameters from dml30_CalculateWriteBackDISPCLK Rejected
drm/amd/display: Drop dm_sw_gfx7_2d_thin_l_vp and dm_sw_gfx7_2d_thin_gl On Review
drm/amd/display: Remove duplicated CalculateWriteBackDISPCLK On Review
drm/amd/display: Remove parameters from rq_dlg_get_dlg_reg On Review
drm/amd/display: Rewrite CalculateWriteBackDISPCLK function On Review
drm/amd/display: Remove unused struct freesync_context Accepted
[PATCH 00/16] Remove entries from struct vba_vars_st On Review
drm/amd/display: Drop XFCEnabled parameter from CalculatePrefetchSchedule On Review
drm/amdgpu: Fix use-after-free on amdgpu_bo_list mutex Accepted
drm/amd/display: Include missing header Accepted

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:

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:

Patch Status
drm/amd/display: Introduce KUnit tests to the bw_fixed library On Review
drm/amd/display: Introduce KUnit tests to the display_mode_vba library On Review
drm/amd/display: Introduce KUnit to dcn20/display_mode_vba_20 library On Review
drm/amd/display: Introduce KUnit tests to dc_dmub_srv library On Review
Documentation/gpu: Add Display Core Unit Test documentation On Review

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:

Date Post
May 26, 2022 I’m in GSoC ‘22
Jun 11, 2022 Linux Kernel Developing with Fedora
Jul 11, 2022 About Kernel Symbol Table, Compilation, and more
Jul 19, 2022 From Selftests to KUnit
Aug 10, 2022 Does the Linux Kernel need software engineering?

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, the Igalia Coding Experience, in which I will be learning more about the DRM subsystem and IGT in the next months. This is making me very excited, as I will continue to contribute with open source, especially the Linux kernel, with the help of my great mentors Melissa Wen and André Almeida, who are software engineers on Igalia.

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.