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:56 PM, Chris Wilson wrote:
On Wed, Apr 01, 2015 at 02:36:29PM +0100, Tvrtko Ursulin wrote:

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"?

When calling the test multiple times successive passes will have a busy
batch, which could conceivably cause the relocations to fail, and the
returned offsets to be -1. Calling gem_sync() before execbuf prevents that
slowpath from affecting the test, without people wondering whether
you need to call gem_sync() before the returned array is valid (which is
why I did a double take here trying to work out what you meant the
gem_sync() to do).

How it may be busy if gem_sync after execbuf is supposed to wait until batch has been retired?

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