From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH i-g-t 1/3] intel-ci: Drop gem_ctx_switch from fast feedback
Date: Mon, 20 Jan 2020 16:02:51 +0200 [thread overview]
Message-ID: <87pnfep6no.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <157952862471.2218.13971330765359216946@skylake-alporthouse-com>
Chris Wilson <chris@chris-wilson.co.uk> writes:
> Quoting Mika Kuoppala (2020-01-20 13:50:46)
>> Chris Wilson <chris@chris-wilson.co.uk> writes:
>>
>> > Only a couple of tests from gem_ctx_switch are run in BAT, to check we
>> > have multiple contexts on RCS. It doesn't actually verify the switch,
>> > just that the execbuf API accepts the context argument.
>> >
>> > This test is redundant as actual context switching (and more) is verified by
>> > live_gem_contexts and live_gt_contexts selftests.
>> >
>> > Instead of using the mediocre gem_ctx_switch stress test in BAT, use
>> > gem_exec_parallel/contexs and gem_exec_parallel/fds as both ensure
>> s/contexs/contexts
>>
>> The gem_exec_parallel seems to use new topology api to set the context.
>> But the aim is to check the context id delivery through rsvd field
>> into execbuf?
>
> gem_ctx_switch was nothing more than see if we can switch without
> blowing up, and spitting out a rough number for context switch latency --
> mostly it was interesting wrt to signal interrupts (for
> intel_ring_submission really). The tests we are _not_ using in BAT.
>
> So as far as basic HW capability goes, we have that covered in selftests.
>
> The question then remains, how best to quickly cover the execbuf.rsvd1
> use cases. gem_exec_parallel seems to be quite good as catching edge
> cases that we overlooked (i.e. has spotted bugs in pre-merging) so seemed
> like the candidate to use here as well.
Ok, thanks for explanation. Yeah interruptible was there but not used
in gem_ctx_switch.
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-01-20 14:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-20 11:36 [Intel-gfx] [PATCH i-g-t 1/3] intel-ci: Drop gem_ctx_switch from fast feedback Chris Wilson
2020-01-20 11:36 ` [Intel-gfx] [PATCH i-g-t 2/3] intel-ci: Reduce variety of gem_sync in BAT Chris Wilson
2020-01-20 13:55 ` Mika Kuoppala
2020-01-20 11:36 ` [Intel-gfx] [PATCH i-g-t 3/3] intel-ci: Use one ringfull example Chris Wilson
2020-01-20 13:53 ` Mika Kuoppala
2020-01-20 13:50 ` [Intel-gfx] [PATCH i-g-t 1/3] intel-ci: Drop gem_ctx_switch from fast feedback Mika Kuoppala
2020-01-20 13:57 ` Chris Wilson
2020-01-20 14:02 ` Mika Kuoppala [this message]
2020-01-20 22:38 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] " 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=87pnfep6no.fsf@gaia.fi.intel.com \
--to=mika.kuoppala@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.