[Intel-gfx] [PATCH i-g-t 1/3] intel-ci: Drop gem_ctx_switch from fast feedback

[Mika Kuoppala]

Chris Wilson <chris at chris-wilson.co.uk> writes:

> Quoting Mika Kuoppala (2020-01-20 13:50:46)
>> Chris Wilson <chris at 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 at linux.intel.com>