Re: [PATCH i-g-t] igt/gem_exec_capture: Fix command emission for gen3

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

 



On Sun, Sep 09, 2018 at 01:43:08PM +0100, Chris Wilson wrote:
> A missing no-op causing us to emit the wrong address when relocation was
> required for BB_START.
> 
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> ---
>  tests/gem_exec_capture.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/gem_exec_capture.c b/tests/gem_exec_capture.c
> index 2dc06ce43..9c26e12c9 100644
> --- a/tests/gem_exec_capture.c
> +++ b/tests/gem_exec_capture.c
> @@ -117,7 +117,7 @@ static void __capture(int fd, int dir, unsigned ring, uint32_t target)
>  		batch[++i] = 0;
>  	}
>  	batch[++i] = 0xc0ffee;
> -	if (gen < 3)
> +	if (gen <= 3)
>  		batch[++i] = MI_NOOP;

This code is rather well obfuscated. Removing the length from
MI_STORE_DWORD_IMM and just setting it correctly in each branch
would go a long way towards making things more obvious.

>  
>  	batch[++i] = MI_BATCH_BUFFER_START; /* not crashed? try again! */
> @@ -144,10 +144,12 @@ static void __capture(int fd, int dir, unsigned ring, uint32_t target)
>  	execbuf.flags = ring;
>  	if (gen > 3 && gen < 6)
>  		execbuf.flags |= I915_EXEC_SECURE;
> +
> +	igt_assert(!READ_ONCE(*seqno));
>  	gem_execbuf(fd, &execbuf);
>  
>  	/* Wait for the request to start */
> -	while (*(volatile uint32_t *)seqno != 0xc0ffee)
> +	while (READ_ONCE(*seqno) != 0xc0ffee)
>  		igt_assert(gem_bo_busy(fd, obj[SCRATCH].handle));
>  	munmap(seqno, 4096);
>  
> -- 
> 2.19.0.rc2
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel
_______________________________________________
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