Re: [PATCH 0/8] drm/amd/display: Introduce KUnit to Display Mode Library
On 8/11/22 08:22, Christian König wrote: Am 11.08.22 um 02:40 schrieb Tales Aparecida: Hello, This series is the consolidation of an RFC sent earlier this year [RFC] bringing unit testing to the AMDPGU driver. [gsoc] Our main goal is to bring unit testing to the AMD display driver; in particular, we'll focus on the Display Mode Library (DML) for DCN2.0, DMUB, and some of the DCE functions. This implementation intends to help developers to recognize bugs before they are merged into the mainline and also makes it possible for future code refactors of the AMD display driver. For the implementation of the tests, we decided to go with the Kernel Unit Testing Framework (KUnit). KUnit makes it possible to run test suites on kernel boot or load the tests as a module. It reports all test case results through a TAP (Test Anything Protocol) in the kernel log. Moreover, KUnit unifies the test structure and provides tools to simplify the testing for developers and CI systems. In regards to CI pipelines, we believe kunit_tool[kunit_tool] provides ease of use, but we are also working on integrating KUnit into IGT, for those already depending on the tool [igt_patch]. We've chosen what we believe to be the simplest approach to integrate KUnit tests into amdgpu [kunit_static]. We took into consideration that this driver relies heavily on static functions with complex behavior which would benefit from unit testing, otherwise, black-box tested through public functions with dozens of arguments and sometimes high cyclomatic complexity. Further than that, this approach also helps beginners by avoiding the need to edit any Makefiles. Other approaches are available and we would gladly receive feedback on this matter. Yeah, that approach immediately trigger goosebumps for me. We should absolutely not do that. The static functions are subject to change and we shouldn't need to change the unit tests when only the internals change. I agree with you that ideally, we should not test static functions. But, considering the scope of the AMD Display Core functions, it is pretty hard to avoid it. Most of the exposed functions on the AMD Display Core have dozens of side effects and some functions pass the 500 lines. In this sense, it is pretty hard to write a proper unit test for the function. If we think through the theory of equivalence partition, when we have two parameters, we have a simple area to analyze the boundary values and the partition. If we have more than 4 parameters, we have a hyperplane with dimension n to analyze, which means that finding the partitions and the boundary values gets harder and harder. In the Display Core, there are static functions with more than 50 parameters and the exposed functions call more the one static function, so we might be analyzing more than 100 parameters, which I don't believe is possible for a unit test. In theory, I agree that we should not test the static functions. But, considering the current scope of the AMD Display code, I don't believe it is viable to test on the exposed functions. Best Regards, - Maíra Canal Instead black box testing and/or exposing tests as a separate module (e.g. for the fixed point calculations for example) is probably the way to go. Just my thoughts on this, essentially our display team has to take a look. Regards, Christian. The first three patches add KUnit represent what we intend to do on the rest of the DML modules: systematic testing of the DML functions, especially mathematically complicated functions. Also, it shows how simple it is to add new tests to the DML. Among the tests, we highlight the dcn20_fpu_test, which, had it existed then, could catch the defects introduced to dcn20_fpu.c by 8861c27a6c [dcn20_bug] later fixed by 9ad5d02c2a [dcn20_fix]. In this series, there's also an example of how unit tests can help avoid regressions and keeping track of changes in behavior. Applying this series on top of the amd-staging-drm-next (2305916dca04) and running its tests will result in a failure in the `dc_dmub_srv` test, you can verify that with: $ ./tools/testing/kunit/kunit.py run --arch=x86_64 \ --kunitconfig=drivers/gpu/drm/amd/display/tests ``` ... [20:19:00] # Subtest: populate_subvp_cmd_drr_info_test [20:19:00] # populate_subvp_cmd_drr_info_test: pass:0 fail:5 skip:0 total:5 [20:19:00] not ok 1 - populate_subvp_cmd_drr_info_test [20:19:00] [FAILED] populate_subvp_cmd_drr_info_test = [20:19:00] # Subtest: dc_dmub_srv [20:19:00] 1..1 [20:19:00] # Totals: pass:0 fail:5 skip:0 total:5 [20:19:00] not ok 8 - dc_dmub_srv [20:19:00] === [FAILED] dc_dmub_srv === [20:19:00] [20:19:00] Testing complete. Passed: 59, Failed: 5, Crashed: 0, Skipped: 0, Errors: 0 ``` Full output at:
Re: [PATCH 0/8] drm/amd/display: Introduce KUnit to Display Mode Library
Am 11.08.22 um 02:40 schrieb Tales Aparecida:
Hello,
This series is the consolidation of an RFC sent earlier this year [RFC]
bringing unit testing to the AMDPGU driver. [gsoc]
Our main goal is to bring unit testing to the AMD display driver; in
particular, we'll focus on the Display Mode Library (DML) for DCN2.0,
DMUB, and some of the DCE functions. This implementation intends to
help developers to recognize bugs before they are merged into the
mainline and also makes it possible for future code refactors of the
AMD display driver.
For the implementation of the tests, we decided to go with the Kernel
Unit Testing Framework (KUnit). KUnit makes it possible to run test
suites on kernel boot or load the tests as a module. It reports all test
case results through a TAP (Test Anything Protocol) in the kernel log.
Moreover, KUnit unifies the test structure and provides tools to
simplify the testing for developers and CI systems.
In regards to CI pipelines, we believe kunit_tool[kunit_tool] provides
ease of use, but we are also working on integrating KUnit into IGT, for
those already depending on the tool [igt_patch].
We've chosen what we believe to be the simplest approach to integrate
KUnit tests into amdgpu [kunit_static]. We took into consideration that
this driver relies heavily on static functions with complex behavior
which would benefit from unit testing, otherwise, black-box tested
through public functions with dozens of arguments and sometimes high
cyclomatic complexity. Further than that, this approach also helps
beginners by avoiding the need to edit any Makefiles. Other approaches
are available and we would gladly receive feedback on this matter.
Yeah, that approach immediately trigger goosebumps for me. We should
absolutely not do that.
The static functions are subject to change and we shouldn't need to
change the unit tests when only the internals change.
Instead black box testing and/or exposing tests as a separate module
(e.g. for the fixed point calculations for example) is probably the way
to go.
Just my thoughts on this, essentially our display team has to take a look.
Regards,
Christian.
The first three patches add KUnit represent what we intend to do on the
rest of the DML modules: systematic testing of the DML functions,
especially mathematically complicated functions. Also, it shows how
simple it is to add new tests to the DML.
Among the tests, we highlight the dcn20_fpu_test, which, had it existed
then, could catch the defects introduced to dcn20_fpu.c by
8861c27a6c [dcn20_bug] later fixed by 9ad5d02c2a [dcn20_fix].
In this series, there's also an example of how unit tests can help avoid
regressions and keeping track of changes in behavior.
Applying this series on top of the amd-staging-drm-next (2305916dca04)
and running its tests will result in a failure in the `dc_dmub_srv`
test, you can verify that with:
$ ./tools/testing/kunit/kunit.py run --arch=x86_64 \
--kunitconfig=drivers/gpu/drm/amd/display/tests
```
...
[20:19:00] # Subtest: populate_subvp_cmd_drr_info_test
[20:19:00] # populate_subvp_cmd_drr_info_test: pass:0 fail:5 skip:0 total:5
[20:19:00] not ok 1 - populate_subvp_cmd_drr_info_test
[20:19:00] [FAILED] populate_subvp_cmd_drr_info_test =
[20:19:00] # Subtest: dc_dmub_srv
[20:19:00] 1..1
[20:19:00] # Totals: pass:0 fail:5 skip:0 total:5
[20:19:00] not ok 8 - dc_dmub_srv
[20:19:00] === [FAILED] dc_dmub_srv ===
[20:19:00]
[20:19:00] Testing complete. Passed: 59, Failed: 5, Crashed: 0, Skipped: 0,
Errors: 0
```
Full output at:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshare.riseup.net%2F%23SOggjANeLfbibdiHu2e_Ugdata=05%7C01%7Cchristian.koenig%40amd.com%7Cb44787cd3628425b078d08da7b3213c7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637957752284993982%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=kiaq3dfpSMiFGkMIXKHhHsMyr7o%2FuvKgny0ifF%2FzrmA%3Dreserved=0
This is due to a known regression introduced by commit 5da7f4134357
("drm/amd/display: fix 32 bit compilation errors in dc_dmub_srv.c")
[dmub_bug], which resulted in the struct's members being zero. As an
exercise, you can revert the offending patch and run the tests again,
but that would still result in failure, albeit with a different output.
Full output when reverted:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshare.riseup.net%2F%23EEBgtgXjAmof5vZ_qs7_sgdata=05%7C01%7Cchristian.koenig%40amd.com%7Cb44787cd3628425b078d08da7b3213c7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637957752284993982%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=%2Flv%2FAOosByeD8vPteKdqGqv2QHf50S6nTNTqma91fm8%3Dreserved=0
This regression is currently being worked on [dmub_fix], and this
test-series will result in
[PATCH 0/8] drm/amd/display: Introduce KUnit to Display Mode Library
Hello,
This series is the consolidation of an RFC sent earlier this year [RFC]
bringing unit testing to the AMDPGU driver. [gsoc]
Our main goal is to bring unit testing to the AMD display driver; in
particular, we'll focus on the Display Mode Library (DML) for DCN2.0,
DMUB, and some of the DCE functions. This implementation intends to
help developers to recognize bugs before they are merged into the
mainline and also makes it possible for future code refactors of the
AMD display driver.
For the implementation of the tests, we decided to go with the Kernel
Unit Testing Framework (KUnit). KUnit makes it possible to run test
suites on kernel boot or load the tests as a module. It reports all test
case results through a TAP (Test Anything Protocol) in the kernel log.
Moreover, KUnit unifies the test structure and provides tools to
simplify the testing for developers and CI systems.
In regards to CI pipelines, we believe kunit_tool[kunit_tool] provides
ease of use, but we are also working on integrating KUnit into IGT, for
those already depending on the tool [igt_patch].
We've chosen what we believe to be the simplest approach to integrate
KUnit tests into amdgpu [kunit_static]. We took into consideration that
this driver relies heavily on static functions with complex behavior
which would benefit from unit testing, otherwise, black-box tested
through public functions with dozens of arguments and sometimes high
cyclomatic complexity. Further than that, this approach also helps
beginners by avoiding the need to edit any Makefiles. Other approaches
are available and we would gladly receive feedback on this matter.
The first three patches add KUnit represent what we intend to do on the
rest of the DML modules: systematic testing of the DML functions,
especially mathematically complicated functions. Also, it shows how
simple it is to add new tests to the DML.
Among the tests, we highlight the dcn20_fpu_test, which, had it existed
then, could catch the defects introduced to dcn20_fpu.c by
8861c27a6c [dcn20_bug] later fixed by 9ad5d02c2a [dcn20_fix].
In this series, there's also an example of how unit tests can help avoid
regressions and keeping track of changes in behavior.
Applying this series on top of the amd-staging-drm-next (2305916dca04)
and running its tests will result in a failure in the `dc_dmub_srv`
test, you can verify that with:
$ ./tools/testing/kunit/kunit.py run --arch=x86_64 \
--kunitconfig=drivers/gpu/drm/amd/display/tests
```
...
[20:19:00] # Subtest: populate_subvp_cmd_drr_info_test
[20:19:00] # populate_subvp_cmd_drr_info_test: pass:0 fail:5 skip:0 total:5
[20:19:00] not ok 1 - populate_subvp_cmd_drr_info_test
[20:19:00] [FAILED] populate_subvp_cmd_drr_info_test =
[20:19:00] # Subtest: dc_dmub_srv
[20:19:00] 1..1
[20:19:00] # Totals: pass:0 fail:5 skip:0 total:5
[20:19:00] not ok 8 - dc_dmub_srv
[20:19:00] === [FAILED] dc_dmub_srv ===
[20:19:00]
[20:19:00] Testing complete. Passed: 59, Failed: 5, Crashed: 0, Skipped: 0,
Errors: 0
```
Full output at: https://share.riseup.net/#SOggjANeLfbibdiHu2e_Ug
This is due to a known regression introduced by commit 5da7f4134357
("drm/amd/display: fix 32 bit compilation errors in dc_dmub_srv.c")
[dmub_bug], which resulted in the struct's members being zero. As an
exercise, you can revert the offending patch and run the tests again,
but that would still result in failure, albeit with a different output.
Full output when reverted: https://share.riseup.net/#EEBgtgXjAmof5vZ_qs7_sg
This regression is currently being worked on [dmub_fix], and this
test-series will result in a success if applied alongside the
fix-series, particularly the patches 1-13/32.
```
[17:48:14] Testing complete. Passed: 64, Failed: 0, Crashed: 0, Skipped: 0,
Errors: 0
```
Full successful output: https://share.riseup.net/#migyN1Xpy3Gyq1it84HhNw
This series depends on a couple of Kunit patches already merged into
torvalds/master, which themselves depends on older patches:
commit 61695f8c5d51 ("kunit: split resource API from test.h into new
resource.h")
commit 2852ca7fba9f ("panic: Taint kernel if tests are run")
commit cfc1d277891e ("module: Move all into module/")
commit cdebea6968fa ("kunit: split resource API impl from test.c into new
resource.c")
commit cae56e1740f5 ("kunit: rename print_subtest_{start,end} for clarity
(s/subtest/suite)")
commit 1cdba21db2ca ("kunit: add ability to specify suite-level init and exit
functions")
commit c272612cb4a2 ("kunit: Taint the kernel when KUnit tests are run")
commit 3d6e44623841 ("kunit: unify module and builtin suite definitions")
commit a02353f49162 ("kunit: bail out of test filtering logic quicker if OOM")
commit 1b11063d32d7 ("kunit: fix executor OOM error handling logic on non-UML")
commit e5857d396f35 ("kunit: flatten kunit_suite*** to kunit_suite** in
.kunit_test_suites")
commit 94681e289bf5
