On Thu, Oct 13, 2016 at 04:25:18PM +0100, Chris Wilson wrote:
> 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.
What about a rpm_resume only version that just does a blind fence_write?
It is something, and we can update the book-keeping once we do get to one
of the real synchronization points again.
With that we can leave the versions for reset and system s/r alone ... Or
is there trickery even with rpm going on?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
