On 01/03/2018 08:08, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-02-28 17:15:19)From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> Verify that the reported busyness is in line with what would we expect from a batch which causes a hang and gets kicked out from the engine. v2: Change to explicit igt_force_gpu_reset instead of guessing when a spin batch will hang. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>It's nice and quick, yes. However, sometime the opposite is true and you have to wait for the batch you want to start before pulling the trigger. I'd put a usleep(100) in there /* Wait for batch to execute */ and we
Hm, but reset is triggered after the first sleep (which checks for 100% busy). So even the non-hanging test flavour could be affect if the delay before execution is so long. So by this logic this usleep(100) (or more for small core CI) should then go to many tests. Only difference in the hang flavour is that if it completely failed to run until after the reset, then the idle assert would fail. So maybe I should just add an assert that the batch is idle before sampling pmu after reset?
Regards, Tvrtko
should put the wait-for-execution ability in igt_spin_t. Unfortunately that requires MI_STORE_DWORD_IMM (or more creativity) limiting it's availability. With the sleep issue addressed (commented upon if nothing else), Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
