[PATCH] drm/xe: Sort again the info flags

[Jani Nikula]

On Thu, 21 Nov 2024, Lucas De Marchi <lucas.demarchi at intel.com> wrote:
> On Thu, Nov 21, 2024 at 12:53:05PM +0200, Jani Nikula wrote:
>>On Wed, 20 Nov 2024, Lucas De Marchi <lucas.demarchi at intel.com> wrote:
>>> IMO we should turn all these "checks run on the build machine" rather
>>> than "checks executed on the target hosts" part of the hooks infra....
>>> because that is much more visible than scripts hidden inside the CI
>>> pipeline. And then people can even run on their own machines.
>>
>>Going on a slight tangent, thinking aloud. Could we split the load more
>>between running on target and running in, say, qemu? Like, there's no
>
> why qemu? does it need HW access? If not, it should just run in the
> build machine that uses UML for "virtualization".

Just tossing ideas! :)

>>point in running some of the drm selftests on each target host. And
>>could we move more towards splitting igt this direction too?
>
> on the xe side we are already running the drm kunit tests that don't
> need HW access:
>
> Example:
> https://patchwork.freedesktop.org/series/141644/
>
> Look at CI.KUnit:
>
> [11:31:03] Starting KUnit Kernel (1/1)...
> [11:31:03] ============================================================
> Running tests with:
> $ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
> [11:31:03] ================== drm_buddy (7 subtests) ==================
> [11:31:03] [PASSED] drm_test_buddy_alloc_limit
> [11:31:03] [PASSED] drm_test_buddy_alloc_optimistic
> [11:31:03] [PASSED] drm_test_buddy_alloc_pessimistic
> [11:31:03] [PASSED] drm_test_buddy_alloc_pathological
> [11:31:03] [PASSED] drm_test_buddy_alloc_contiguous
> [11:31:03] [PASSED] drm_test_buddy_alloc_clear
> [11:31:03] [PASSED] drm_test_buddy_alloc_range_bias
> [11:31:03] ==================== [PASSED] drm_buddy ====================
> [11:31:03] ============= drm_cmdline_parser (40 subtests) =============
> [11:31:03] [PASSED] drm_test_cmdline_force_d_only
> [11:31:03] [PASSED] drm_test_cmdline_force_D_only_dvi
> [11:31:03] [PASSED] drm_test_cmdline_force_D_only_hdmi
> [11:31:03] [PASSED] drm_test_cmdline_force_D_only_not_digital
> [11:31:03] [PASSED] drm_test_cmdline_force_e_only
> [11:31:03] [PASSED] drm_test_cmdline_res
> [11:31:03] [PASSED] drm_test_cmdline_res_vesa
> [11:31:03] [PASSED] drm_test_cmdline_res_vesa_rblank
> [11:31:03] [PASSED] drm_test_cmdline_res_rblank
> ...
>
>
> These are SW-only tests that are already executed as part of each patch
> series. We also have SW-only tests for xe in the same place:
>
> [11:30:38] Starting KUnit Kernel (1/1)...
> [11:30:38] ============================================================
> Running tests with:
> $ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
> [11:30:39] =================== guc_dbm (7 subtests) ===================
> [11:30:39] [PASSED] test_empty
> ...
>
> Is this what you mean by drm selftests or did I misinterpret it?

Yes!

BR,
Jani.


>
> Looking at https://intel-gfx-ci.01.org/tree/drm-tip/shards-all.html?testfilter=selftest
> it seems some of the tests need HW access?
>
> In xe we split what is SW-only from what needs HW access because of
> this...  all kunit tests that need HW are inside xe_live_ktest, that
> provides the igt integration (there's also a slight preference on not
> using kunit for that too, but that varies depending who you talk to and
> how much it's a unit vs integration test). Tests that are SW-only are
> executed by build machines, they don't need to run on each target.
>
> Lucas De Marchi
>
>>
>>BR,
>>Jani.
>>
>>
>>-- 
>>Jani Nikula, Intel

-- 
Jani Nikula, Intel