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. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
