Re: [PATCH 3/3] igt/kms_flip: Use new igt_spin_batch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux