summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/scheduler/tests
AgeCommit message (Collapse)Author
2026-05-29drm/sched: Fix clang build warning in kunit testsTvrtko Ursulin
Initializing compile time constant struct or arrays from another such variable is a gcc extension, while clang strictly requires a compile time constant literal. As reported by LKP: >> drivers/gpu/drm/scheduler/tests/tests_scheduler.c:675:10: error: initializer element is not a compile-time constant drm_sched_scheduler_two_clients_attr), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/kunit/test.h:224:13: note: expanded from macro 'KUNIT_CASE_PARAM_ATTR' .attr = attributes, .module_name = KBUILD_MODNAME} ^~~~~~~~~~ 1 error generated. vim +675 drivers/gpu/drm/scheduler/tests/tests_scheduler.c 671 672 static struct kunit_case drm_sched_scheduler_two_clients_tests[] = { 673 KUNIT_CASE_PARAM_ATTR(drm_sched_scheduler_two_clients_test, 674 drm_sched_scheduler_two_clients_gen_params, > 675 drm_sched_scheduler_two_clients_attr), 676 {} 677 }; 678 Fix it by using a compound literal as other tests do. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202605220312.Pu7UO05u-lkp@intel.com/ Fixes: 97ef806a5314 ("drm/sched: Add some scheduling quality unit tests") Cc: Philipp Stanner <phasta@kernel.org> Acked-by: Philipp Stanner <phasta@kernel.org> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260522090129.9385-1-tvrtko.ursulin@igalia.com
2026-04-17drm/sched: Remove drm_sched_init_args->num_rqs usageTvrtko Ursulin
Remove member no longer used by the scheduler core. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Philipp Stanner <phasta@kernel.org> Cc: Christian König <ckoenig.leichtzumerken@gmail.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260417103744.76020-27-tvrtko.ursulin@igalia.com
2026-04-17drm/sched: Add some more scheduling quality unit testsTvrtko Ursulin
This time round we explore the rate of submitted job queue processing with multiple identical parallel clients. Example test output: 3 clients: t cycle: min avg max : ... + 0ms 0 0 0 : 0 0 0 + 102ms 2 2 2 : 2 2 2 + 208ms 5 6 6 : 6 5 5 + 310ms 8 9 9 : 9 9 8 ... + 2616ms 82 83 83 : 83 83 82 + 2717ms 83 83 83 : 83 83 83 avg_max_min_delta(x100)=60 Every 100ms for the duration of the test it logs how many jobs each client had completed, prefixed by minimum, average and maximum numbers. When finished overall average delta between max and min is output as a rough indicator to scheduling fairness. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260417103744.76020-6-tvrtko.ursulin@igalia.com
2026-04-17drm/sched: Add some scheduling quality unit testsTvrtko Ursulin
To make evaluating different scheduling policies easier (no need for external benchmarks) and perfectly repeatable, lets add some synthetic workloads built upon mock scheduler unit test infrastructure. Focus is on two parallel clients (two threads) submitting different job patterns and logging their progress and some overall metrics. This is repeated for both scheduler credit limit 1 and 2. Example test output: Normal and low: pct1 cps1 qd1; pct2 cps2 qd2 + 0ms: 0 0 0; 0 0 0 + 104ms: 100 1240 112; 100 1240 125 + 209ms: 100 0 99; 100 0 125 + 313ms: 100 0 86; 100 0 125 + 419ms: 100 0 73; 100 0 125 + 524ms: 100 0 60; 100 0 125 + 628ms: 100 0 47; 100 0 125 + 731ms: 100 0 34; 100 0 125 + 836ms: 100 0 21; 100 0 125 + 939ms: 100 0 8; 100 0 125 + 1043ms: ; 100 0 120 + 1147ms: ; 100 0 107 + 1252ms: ; 100 0 94 + 1355ms: ; 100 0 81 + 1459ms: ; 100 0 68 + 1563ms: ; 100 0 55 + 1667ms: ; 100 0 42 + 1771ms: ; 100 0 29 + 1875ms: ; 100 0 16 + 1979ms: ; 100 0 3 0: prio=normal sync=0 elapsed_ms=1015ms (ideal_ms=1000ms) cycle_time(min,avg,max)=134,222,978 us latency_time(min,avg,max)=134,222,978 us 1: prio=low sync=0 elapsed_ms=2009ms (ideal_ms=1000ms) cycle_time(min,avg,max)=134,215,806 us latency_time(min,avg,max)=134,215,806 us There we have two clients represented in the two respective columns, with their progress logged roughly every 100 milliseconds. The metrics are: - pct - Percentage progress of the job submit part - cps - Cycles per second - qd - Queue depth - number of submitted unfinished jobs The cycles per second metric is inherent to the fact that workload patterns are a data driven cycling sequence of: - Submit 1..N jobs - Wait for Nth job to finish (optional) - Sleep (optional) - Repeat from start In this particular example we have a normal priority and a low priority client both spamming the scheduler with 8ms jobs with no sync and no sleeping. Hence they build very deep queues and we can see how the low priority client is completely starved until the normal finishes. Note that the PCT and CPS metrics are irrelevant for "unsync" clients since they manage to complete all of their cycles instantaneously. A different example would be: Heavy and interactive: pct1 cps1 qd1; pct2 cps2 qd2 + 0ms: 0 0 0; 0 0 0 + 106ms: 5 40 3; 5 40 0 + 209ms: 9 40 0; 9 40 0 + 314ms: 14 50 3; 14 50 0 + 417ms: 18 40 0; 18 40 0 + 522ms: 23 50 3; 23 50 0 + 625ms: 27 40 0; 27 40 1 + 729ms: 32 50 0; 32 50 0 + 833ms: 36 40 1; 36 40 0 + 937ms: 40 40 0; 40 40 0 + 1041ms: 45 50 0; 45 50 0 + 1146ms: 49 40 1; 49 40 1 + 1249ms: 54 50 0; 54 50 0 + 1353ms: 58 40 1; 58 40 0 + 1457ms: 62 40 0; 62 40 1 + 1561ms: 67 50 0; 67 50 0 + 1665ms: 71 40 1; 71 40 0 + 1772ms: 76 50 0; 76 50 0 + 1877ms: 80 40 1; 80 40 0 + 1981ms: 84 40 0; 84 40 0 + 2085ms: 89 50 0; 89 50 0 + 2189ms: 93 40 1; 93 40 0 + 2293ms: 97 40 0; 97 40 1 In this case client one is submitting 3x 2.5ms jobs, waiting for the 3rd and then sleeping for 2.5ms (in effect causing 75% GPU load, minus the overheads). Second client is submitting 1ms jobs, waiting for each to finish and sleeping for 9ms (effective 10% GPU load). Here we can see the PCT and CPS reflecting real progress. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260417103744.76020-5-tvrtko.ursulin@igalia.com
2026-02-27drm/tests: Mark slow tests as slowMaxime Ripard
Some DRM tests cross the 1s execution time threshold that defines a test as slow. Let's flag them as such. Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260224110310.1854608-1-mripard@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-09-19drm/sched/tests: Remove relict of done_listPhilipp Stanner
A rework of the scheduler unit tests removed the done_list. That list is still mentioned in the mock test header. Remove that relict. Fixes: 4576de9b7977 ("drm/sched/tests: Implement cancel_job() callback") Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250919064450.147176-2-phasta@kernel.org
2025-08-28drm/sched/tests: Remove redundant header filesLiao Yuanhong
The header file <linux/atomic.h> is already included on line 8. Remove the redundant include. Fixes: 5a99350794fec ("drm/sched: Add scheduler unit testing infrastructure and some basic tests") Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250819142630.368796-1-liaoyuanhong@vivo.com
2025-07-17drm/sched: Fix a race in DRM_GPU_SCHED_STAT_NO_HANG testTvrtko Ursulin
The "skip reset" test waits for the timeout handler to run for the duration of 2 * MOCK_TIMEOUT, and because the mock scheduler opted to remove the "skip reset" flag once it fires, this gives opportunity for the timeout handler to run twice. Second time the job will be removed from the mock scheduler job list and the drm_mock_sched_advance() call in the test will fail. Fix it by making the "don't reset" flag persist for the lifetime of the job and add a new flag to verify that the code path had executed as expected. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: 1472e7549f84 ("drm/sched: Add new test for DRM_GPU_SCHED_STAT_NO_HANG") Cc: Maíra Canal <mcanal@igalia.com> Cc: Philipp Stanner <phasta@kernel.org> Reviewed-by: Maíra Canal <mcanal@igalia.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250716084817.56797-1-tvrtko.ursulin@igalia.com
2025-07-15drm/sched: Add new test for DRM_GPU_SCHED_STAT_NO_HANGMaíra Canal
Add a test to submit a single job against a scheduler with the timeout configured and verify that if the job is still running, the timeout handler will skip the reset and allow the job to complete. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250714-sched-skip-reset-v6-4-5c5ba4f55039@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2025-07-15drm/sched: Make timeout KUnit tests fasterMaíra Canal
As more KUnit tests are introduced to evaluate the basic capabilities of the `timedout_job()` hook, the test suite will continue to increase in duration. To reduce the overall running time of the test suite, decrease the scheduler's timeout for the timeout tests. Before this commit: [15:42:26] Elapsed time: 15.637s total, 0.002s configuring, 10.387s building, 5.229s running After this commit: [15:45:26] Elapsed time: 9.263s total, 0.002s configuring, 5.168s building, 4.037s running Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Acked-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250714-sched-skip-reset-v6-3-5c5ba4f55039@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2025-07-15drm/sched: Rename DRM_GPU_SCHED_STAT_NOMINAL to DRM_GPU_SCHED_STAT_RESETMaíra Canal
Among the scheduler's statuses, the only one that indicates an error is DRM_GPU_SCHED_STAT_ENODEV. Any status other than DRM_GPU_SCHED_STAT_ENODEV signifies that the operation succeeded and the GPU is in a nominal state. However, to provide more information about the GPU's status, it is needed to convey more information than just "OK". Therefore, rename DRM_GPU_SCHED_STAT_NOMINAL to DRM_GPU_SCHED_STAT_RESET, which better communicates the meaning of this status. The status DRM_GPU_SCHED_STAT_RESET indicates that the GPU has hung, but it has been successfully reset and is now in a nominal state again. Reviewed-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250714-sched-skip-reset-v6-1-5c5ba4f55039@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2025-07-10drm/sched/tests: Add unit test for cancel_job()Philipp Stanner
The scheduler unit tests now provide a new callback, cancel_job(). This callback gets used by drm_sched_fini() for all still pending jobs to cancel them. Implement a new unit test to test this. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250710125412.128476-6-phasta@kernel.org
2025-07-10drm/sched/tests: Implement cancel_job() callbackPhilipp Stanner
The GPU Scheduler now supports a new callback, cancel_job(), which lets the scheduler cancel all jobs which might not yet be freed when drm_sched_fini() runs. Using this callback allows for significantly simplifying the mock scheduler teardown code. Implement the cancel_job() callback and adjust the code where necessary. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250710125412.128476-5-phasta@kernel.org
2025-06-30drm/sched/tests: Make timedout_job callback a better role modelPhilipp Stanner
Since the drm_mock_scheduler does not have real users in userspace, nor does it have real hardware or firmware rings, it's not necessary to signal timedout fences nor free jobs - from a functional standpoint. Still, the dma_fence framework establishes the hard rule that all fences must always get signaled. The unit tests, moreover, should as much as possible represent the intended usage of the scheduler API. Furthermore, this later enables simplifying the mock scheduler's teardown code path. Make sure timed out hardware fences get signaled with the appropriate error code. Signed-off-by: Philipp Stanner <phasta@kernel.org> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250605134154.191764-2-phasta@kernel.org
2025-06-02drm/sched/tests: Use one lock for fence contextPhilipp Stanner
There is no need for separate locks for single jobs and the entire scheduler. The dma_fence context can be protected by the scheduler lock, allowing for removing the jobs' locks. This simplifies things and reduces the likelyhood of deadlocks etc. Replace the jobs' locks with the mock scheduler lock. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250527101029.56491-2-phasta@kernel.org
2025-05-28drm/sched: Store the drm client_id in drm_sched_fencePierre-Eric Pelloux-Prayer
This will be used in a later commit to trace the drm client_id in some of the gpu_scheduler trace events. This requires changing all the users of drm_sched_job_init to add an extra parameter. The newly added drm_client_id field in the drm_sched_fence is a bit of a duplicate of the owner one. One suggestion I received was to merge those 2 fields - this can't be done right now as amdgpu uses some special values (AMDGPU_FENCE_OWNER_*) that can't really be translated into a client id. Christian is working on getting rid of those; when it's done we should be able to squash owner/drm_client_id together. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250526125505.2360-3-pierre-eric.pelloux-prayer@amd.com
2025-04-07Merge drm/drm-next into drm-misc-nextThomas Zimmermann
Backmerging to get v6.15-rc1 into drm-misc-next. Also fixes a build issue when enabling CONFIG_DRM_SCHED_KUNIT_TEST. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2025-03-24drm/sched: Add a basic test for checking credit limitTvrtko Ursulin
Add a basic test for checking whether scheduler respects the configured credit limit. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250324092633.49746-7-tvrtko.ursulin@igalia.com
2025-03-24drm/sched: Add a basic test for modifying entities scheduler listTvrtko Ursulin
Add a basic test for exercising modifying the entities scheduler list at runtime. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250324092633.49746-6-tvrtko.ursulin@igalia.com
2025-03-24drm/sched: Add basic priority testsTvrtko Ursulin
Add some basic tests for exercising entity priority handling. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250324092633.49746-5-tvrtko.ursulin@igalia.com
2025-03-24drm/sched: Add a simple timeout testTvrtko Ursulin
Add a very simple timeout test which submits a single job and verifies that the timeout handling will run if the backend failed to complete the job in time. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250324092633.49746-4-tvrtko.ursulin@igalia.com
2025-03-24drm/sched: Add scheduler unit testing infrastructure and some basic testsTvrtko Ursulin
Implement a mock scheduler backend and add some basic test to exercise the core scheduler code paths. Mock backend (kind of like a very simple mock GPU) can either process jobs by tests manually advancing the "timeline" job at a time, or alternatively jobs can be configured with a time duration in which case they get completed asynchronously from the unit test code. Core scheduler classes are subclassed to support this mock implementation. The tests added are just a few simple submission patterns. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Suggested-by: Philipp Stanner <phasta@kernel.org> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250324092633.49746-3-tvrtko.ursulin@igalia.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-07-21 06:37:09 +0000