Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > Quoting Mika Kuoppala (2020-01-20 13:50:46) >> Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
