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).
> >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.
Calling igt_drop_caches_set() is reasonable enough to in the preamble.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
