Commit 5424f5d7 authored by Chris Wilson's avatar Chris Wilson

drm/i915: Clear the GGTT_WRITE bit on unbinding the vma

While we do flush writes to the vma before unbinding (to make sure they
go through the right detiling register), we may also be concurrently
poking at the GGTT_WRITE bit from set-domain, as we mark all GGTT vma
associated with an object. We know this is for another vma, as we
are currently unbinding this one -- so if this vma will be reused, it
will be refaulted and have its dirty bit set before the next write.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/999Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200121222447.419489-1-chris@chris-wilson.co.uk
parent d2a4bb6f
......@@ -1218,9 +1218,15 @@ int __i915_vma_unbind(struct i915_vma *vma)
* before the unbind, other due to non-strict nature of those
* indirect writes they may end up referencing the GGTT PTE
* after the unbind.
*
* Note that we may be concurrently poking at the GGTT_WRITE
* bit from set-domain, as we mark all GGTT vma associated
* with an object. We know this is for another vma, as we
* are currently unbinding this one -- so if this vma will be
* reused, it will be refaulted and have its dirty bit set
* before the next write.
*/
i915_vma_flush_writes(vma);
GEM_BUG_ON(i915_vma_has_ggtt_write(vma));
/* release the fence reg _after_ flushing */
ret = i915_vma_revoke_fence(vma);
......@@ -1240,7 +1246,8 @@ int __i915_vma_unbind(struct i915_vma *vma)
trace_i915_vma_unbind(vma);
vma->ops->unbind_vma(vma);
}
atomic_and(~(I915_VMA_BIND_MASK | I915_VMA_ERROR), &vma->flags);
atomic_and(~(I915_VMA_BIND_MASK | I915_VMA_ERROR | I915_VMA_GGTT_WRITE),
&vma->flags);
i915_vma_detach(vma);
vma_unbind_pages(vma);
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment