On Thu, Oct 13, 2016 at 05:10:21PM +0200, Daniel Vetter wrote:
> On Wed, Oct 12, 2016 at 12:16:33PM +0100, Chris Wilson wrote:
> > @@ -379,10 +389,17 @@ void i915_gem_restore_fences(struct drm_device *dev)
> > * Commit delayed tiling changes if we have an object still
> > * attached to the fence, otherwise just clear the fence.
> > */
> > - if (vma && !i915_gem_object_is_tiled(vma->obj))
> > + if (vma && !i915_gem_object_is_tiled(vma->obj)) {
> > + GEM_BUG_ON(!reg->dirty);
> > + GEM_BUG_ON(!list_empty(&vma->obj->userfault_link));
> > +
> > + list_move(®->link, &dev_priv->mm.fence_list);
> > + vma->fence = NULL;
> > vma = NULL;
> > + }
> >
> > - fence_update(reg, vma);
> > + fence_write(reg, vma);
> > + reg->vma = vma;
>
> Same comments as with the userfault_list: Using rpm ordering to enforce
> consistency causes mild panic attacks here with me ;-)
>
> Is the above (delayed tiling change commit) even possible here, at least
> for rpm resume? Same for system s/r (both s3 and s4) since the pagetables
> won't survive anyway. Can't we simply make this an impossibility?
We also use this from reset to rewrite the old fences, and we know there
we can hit the delayed fence write [4fc788f5ee3d]. It would also be
possible to hit it on suspend as well.
I've been thinking about whether we should be bothering to write the
fence registers with the correct value or just cancel the fences. But we
have to restore anything that is pinned, and we have to write something
into the fences (just to be safe), and if we have to write something we
may as well use the most recent information we have as that has a good
chance of being used again.
Long story short, I don't have a better idea for restoring or avoiding
the restore of fences.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
