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
> Cc: Joonas Lahtinen
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
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
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
