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 05:07:25PM +0100, Tvrtko Ursulin wrote:
> 
> On 04/01/2015 04:42 PM, Chris Wilson wrote:
> >On Wed, Apr 01, 2015 at 04:14:52PM +0100, Tvrtko Ursulin wrote:
> >>+	/* 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 don't get this. B starts after A + padding, but B ends before A?

s/&&/||/ 

> >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)?
> 
> I thought my test logic is pretty straightforward:
> 
> 1. Find two objects next to each other.
> 2. Add padding on the "lower" (addressed) object.
> 3. Ensure objects are now apart at least what the padding is.

What should happen is:

Initial layout:

|    ||aa||bb|
batch A   B

(B_offset == A_offset + PAGE)

We then submit an execbuf with A_pad_to_size = 2*PAGE, the kernel will
unbind A, keep B, then bind A (given an empty GTT):

|    |xxxx|bb||aaaaaa|
batch      B  A

but the distance here is just 1 PAGE. Then if B_pad_to_size is set to
2*PAGE:

|    |xxxxxxxx|aaaaaa||bbbbbb|
batch         A       B

If both are initially set to pad_to_size = 2*PAGE, we should see something
like:

|    ||aaaaaa||bbbbbb|
batch A       B

Given that the assertion should just be that the new objects do not
overlap assuming their size is now pad_to_size.
-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