| Message ID | 20180621073205.26701-1-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Quoting Chris Wilson (2018-06-21 10:32:05) > We only need to apply the BIAS for self-relocations into the batchbuffer > iff the execobject has any relocations. > > This suppresses some warnings we may get with a full gtt (so the batch > object has wound up at 0 from a previous invocation), but doesn't fix > the underlying problem of how we tried to move a pinned batch vma (how > we have a pinned user vma outside of execbuf, I do not know, though this > being on an aliasing ppgtt means it could be a spurious pinning via the > global gtt). One step at a time... > > References: https://bugs.freedesktop.org/show_bug.cgi?id=106744#c1 > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Long commit message short; don't need to bias the batch buffer if it doesn't reference itself via an address... Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Regards, Joonas > --- > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > index 60dc2a865f5f..437441f4af41 100644 > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > @@ -534,7 +534,8 @@ eb_add_vma(struct i915_execbuffer *eb, > * paranoia do it everywhere. > */ > if (i == batch_idx) { > - if (!(eb->flags[i] & EXEC_OBJECT_PINNED)) > + if (entry->relocation_count && > + !(eb->flags[i] & EXEC_OBJECT_PINNED)) > eb->flags[i] |= __EXEC_OBJECT_NEEDS_BIAS; > if (eb->reloc_cache.has_fence) > eb->flags[i] |= EXEC_OBJECT_NEEDS_FENCE; > -- > 2.18.0.rc2 >
Quoting Patchwork (2018-06-21 08:51:28) > ==== Possible fixes ==== > > igt@gem_exec_gttfill@basic: > fi-byt-n2820: FAIL (fdo#106744) -> PASS Flipper be gone, thanks for the kind review, -Chris
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 60dc2a865f5f..437441f4af41 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -534,7 +534,8 @@ eb_add_vma(struct i915_execbuffer *eb, * paranoia do it everywhere. */ if (i == batch_idx) { - if (!(eb->flags[i] & EXEC_OBJECT_PINNED)) + if (entry->relocation_count && + !(eb->flags[i] & EXEC_OBJECT_PINNED)) eb->flags[i] |= __EXEC_OBJECT_NEEDS_BIAS; if (eb->reloc_cache.has_fence) eb->flags[i] |= EXEC_OBJECT_NEEDS_FENCE;
We only need to apply the BIAS for self-relocations into the batchbuffer iff the execobject has any relocations. This suppresses some warnings we may get with a full gtt (so the batch object has wound up at 0 from a previous invocation), but doesn't fix the underlying problem of how we tried to move a pinned batch vma (how we have a pinned user vma outside of execbuf, I do not know, though this being on an aliasing ppgtt means it could be a spurious pinning via the global gtt). One step at a time... References: https://bugs.freedesktop.org/show_bug.cgi?id=106744#c1 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)