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 <ch...@chris-wilson.co.uk> >> Cc: Daniel Vetter <daniel.vet...@ffwll.ch> >> Signed-off-by: Abdiel Janulgue <abdiel.janul...@linux.intel.com> >> --- >> 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@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
