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

[Chris Wilson]

On Wed, Apr 01, 2015 at 03:14:26PM +0100, Tvrtko Ursulin wrote:
> 
> 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?

It's not. I am trying to say that the placement of gem_sync() here
suggests to me that you thought it was required to get valid offsets
after an execbuf call. But in actualilty you do not need a gem_sync() in
this test at all as you are not doing relocations.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre