intel-xe.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>,
	intel-xe@lists.freedesktop.org,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	ryszard.knop@intel.com
Subject: Re: [PATCH] drm/xe: Sort again the info flags
Date: Mon, 25 Nov 2024 17:36:26 +0200	[thread overview]
Message-ID: <87frnfxr45.fsf@intel.com> (raw)
In-Reply-To: <4urb7iogs2b2wkznlix2jnhflgb7izryfzsp2yz2ux4bx7xv5l@lt2w26ab52af>

On Thu, 21 Nov 2024, Lucas De Marchi <lucas.demarchi@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@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

  reply	other threads:[~2024-11-25 15:36 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-18 22:33 [PATCH] drm/xe: Sort again the info flags Lucas De Marchi
2024-11-18 23:05 ` ✓ CI.Patch_applied: success for " Patchwork
2024-11-18 23:05 ` ✓ CI.checkpatch: " Patchwork
2024-11-18 23:06 ` ✓ CI.KUnit: " Patchwork
2024-11-18 23:14 ` [PATCH] " Cavitt, Jonathan
2024-11-18 23:24 ` ✓ CI.Build: success for " Patchwork
2024-11-18 23:26 ` ✓ CI.Hooks: " Patchwork
2024-11-18 23:28 ` ✓ CI.checksparse: " Patchwork
2024-11-18 23:50 ` ✓ CI.BAT: " Patchwork
2024-11-19 10:51 ` [PATCH] " Matthew Auld
2024-11-19 17:08   ` Lucas De Marchi
2024-11-20 12:16     ` Jani Nikula
2024-11-20 14:16       ` Lucas De Marchi
2024-11-21 10:53         ` Jani Nikula
2024-11-21 16:54           ` Lucas De Marchi
2024-11-25 15:36             ` Jani Nikula [this message]
2024-11-19 11:04 ` ✗ CI.FULL: failure for " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87frnfxr45.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.auld@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=ryszard.knop@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).