[igt-dev] [PATCH i-g-t 0/7] Prepare IGTs to allow only zero alignment

[Dixit, Ashutosh]

On Thu, 14 Oct 2021 08:53:06 -0700, Zbigniew Kempczyński wrote:
>
> On Thu, Oct 14, 2021 at 08:28:30AM -0700, Dixit, Ashutosh wrote:
> > On Thu, 14 Oct 2021 01:19:10 -0700, Zbigniew Kempczyński wrote:
> > >
> > > In the future we're planning to allow passing only zero alignment so
> > > this is preparation step to introduce check and disable or fix
> > > igts which uses this constraint.
> > >
> > > v2: rename to gem_allows_obj_alignment() (Ashutosh)
> > >     addressing review comments from Ashutosh
> > >
> >
> > For patches 1 through 6:
> >
> > Reviewed-by: Ashutosh Dixit <ashutosh.dixit at intel.com>
> >
> > For patch 7, I think the point below from my earlier email is still
> > unaddressed:
> >
> > > So assigning a new offset will cause a new fault-in (bind) but not sure if
> > > it will cause an actual fault-out (unbind). Though I am not sure if there
> > > is actually a way to force it to happen if this doesn't work? Is there a
> > > way to verify that the unbind is actually happening?
> >
> > Maybe if assign the same offset to a different object/page that will cause
> > a fault-out (unbind) followed by a fault-in (bind).
>
> For softpin case if you're changing the offset i915 will unbind/bind vma
> in ppgtt, see eb_vma_misplaced() condition:
>
>	if (flags & EXEC_OBJECT_PINNED &&
>	    vma->node.start != entry->offset)
>		return true;
>
> so when you will go out from eb_pin_vma() with an error in else {} part
> i915_vma_unbind() will be called. You can verify this using dynamic ftrace.

Actually makes sense that if an object moves to a different offset that it
will be unbound from the previous offset. So yes this should work.