Re: [RFC i-g-t v3] tests/gem_exec_pad_to_size: Test object padding at execbuf

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

 



On Wed, Apr 01, 2015 at 04:14:52PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
> 
> This tests the new EXEC_OBJECT_PAD_TO_SIZE exec_object2 flag.
> 
> Similar to some other tests, it uses knowledge of the DRM
> allocation policy in order to get two objects mapped adjacent
> to each other. It is then possible to verify that the pad to
> size flag will move them apart.
> 
> v2: Correct commit message. (Chris Wilson)
> v3: Changes after code review by Chris Wilson.
>      * No need for gem_sync after execbuf.
>      * Drop caches before running.
>      * Allocate one additional bo per iteration.
>      * Don't explicitly set unused execbuf fields to zero.
>      * One improved comment.

Ah, sorry to be a nuisance, I'm getting to the actual test finally!

> +	/* Re-exec with padding set. */
> +	igt_assert(exec(fd, eb_handles, pad_to_size, offsets) == 0);

The crux of the test is that we generate two objects such that

B_offset = A_offset + A_size

and then tell the kernel that A is actually 2*size (A_pad_to_size)

> +	if (offsets[1] > offsets[0])
> +		distance = offsets[1] - offsets[0];
> +	else
> +		distance = offsets[0] - offsets[1];

The assertion I feel should only be that

B_offset + B_size <= A_offset && B_offset >= A_offset + A_pad_to_size

i.e. that they are now disjoint.

Your test is valid nevertheless, it is the ordering of the objects that
is confusing.

Hmm, can you loop until B_offset == A_offset + A_size such that we don't
have the confusion with order? And even assert that A_offset is
unchanged (though that smells like a little to much internal knowledge
leaking through, it is a desirable property of the allocator though - no
unnecessarily eviction) afterwards.

Do you agree that losing the handling of negative distances will make
the test simpler to understand (at the expense of doing more work in the
setup)?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://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