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 <ch...@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
---
 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

Reply via email to