Quoting Joonas Lahtinen (2017-11-01 13:17:11)
> On Tue, 2017-10-31 at 10:36 +0000, Chris Wilson wrote:
> > In case the object has changed tiling between calls to execbuf, we need
> > to check if the existing offset inside the GTT matches the new tiling
> > constraint. We even need to do this for "unfenced" tiled objects, where
> > the 3D commands use an implied fence and so the object still needs to
> > match the physical fence restrictions on alignment (only required for
> > gen2 and early gen3).
> >
> > In commit 2889caa92321 ("drm/i915: Eliminate lots of iterations over
> > the execobjects array"), the idea was to remove the second guessing and
> > only set the NEEDS_MAP flag when required. However, the entire check
> > for an unusable offset for fencing was removed and not just the
> > secondary check. I.e.
> >
> > /* avoid costly ping-pong once a batch bo ended up non-mappable */
> > if (entry->flags & __EXEC_OBJECT_NEEDS_MAP &&
> > !i915_vma_is_map_and_fenceable(vma))
> > return !only_mappable_for_reloc(entry->flags);
> >
> > was entirely removed as the ping-pong between execbuf passes was fixed,
> > but its primary purpose in forcing unaligned unfenced access to be
> > rebound was forgotten.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103502
> > Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array")
> > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
>
> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
Ta. So I'd been pondering how to catch this in CI. In theory, this could
be caught by gem_render_tiled_blit, but it firstly requires checking
that the rendercopy routines use the implicit fence instructions and
secondary we need lots of repetitions with interleaved set-tiling to try
and cause an address conflict. And then we have only one machine in the
farm that is even susceptible to this bug...
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
