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

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

 




On 04/01/2015 02:06 PM, Chris Wilson wrote:
On Wed, Apr 01, 2015 at 12:21:14PM +0100, Tvrtko Ursulin wrote:
+	if (drmIoctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, &execbuf))
+			ret = -errno;

+	if (ret == 0) {
+		gem_sync(fd, handles[0]);
Not required for this test. However... You probably want to do the
gem_sync() first. (Yes, there is an amusing reason to do :)

What reason is that and what do you mean by "first"?

+	for (try = 0, idx = 0; try < max_tries;) {
+		eb_handles[0] = handles[0];
+		eb_handles[1] = loc_handles[idx];
+		eb_handles[2] = loc_handles[idx + 1];
+
+		igt_assert(exec(fd, eb_handles, (uint32_t[2]){0, 0},
+				offsets) == 0);
+
+		if (offsets[1] > offsets[0]) {
+			distance = offsets[1] - offsets[0];
+			if (distance == PAGE_SIZE)
+				neighbours = true;
+			pad_to_size[0] = ALIGN(distance + PAGE_SIZE, PAGE_SIZE);
+		} else {
+			distance = offsets[0] - offsets[1];
+			if (distance == PAGE_SIZE)
+				neighbours = true;
+			pad_to_size[1] = ALIGN(distance + PAGE_SIZE, PAGE_SIZE);
+		}
+
+		if (neighbours)
+			break;
+
+		try++;
+		idx +=2;

Just use idx++ here and allocate a new handle one at a time. Just as
likely to be adjacent to the previous handle as the next one will be to

Ah yes, didn't think of that!

us. For extra paranoia, you could even try an evict-everything pass :)

You mean if the lightweight approach fails? Ok.

Regards,

Tvrtko
_______________________________________________
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