On 10/28/2016 07:02 PM, Ville Syrjälä wrote: > On Fri, Oct 28, 2016 at 06:47:26PM +0300, Abdiel Janulgue wrote: >> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> >> Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> >> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@xxxxxxxxxxxxxxx> >> --- >> tests/kms_flip.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/tests/kms_flip.c b/tests/kms_flip.c >> index 9829b35..13cb262 100644 >> --- a/tests/kms_flip.c >> +++ b/tests/kms_flip.c >> @@ -866,10 +866,10 @@ static unsigned int run_test_step(struct test_output *o) >> o->current_fb_id = !o->current_fb_id; >> >> if (o->flags & TEST_WITH_DUMMY_BCS) >> - emit_dummy_load__bcs(o, 1); >> + igt_spin_batch_wait(drm_fd, 1, I915_EXEC_BLT); >> >> if (o->flags & TEST_WITH_DUMMY_RCS) >> - emit_dummy_load__rcs(o, 1); >> + igt_spin_batch_wait(drm_fd, 1, I915_EXEC_RENDER); > > NAK That's not going to add the required dependency between the load > and the bo used by the test. Right. For these cases would it be more straightforward to stick to the auto-tuned rendercopy/blit load operations on the bo instead of inserting a recursive batch on these situations? Any ideas? >> >> if (o->flags & TEST_FB_RECREATE) >> recreate_fb(o); >> -- >> 2.7.0 >> >> _______________________________________________ >> 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
