[Intel-gfx] [resend] drm/i915: Check incoming alignment for unfenced buffers (on i915gm)

Chris Wilson chris at chris-wilson.co.uk
Wed Nov 1 13:46:46 UTC 2017


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 at chris-wilson.co.uk>
> > Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> 
> Reviewed-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>

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


More information about the Intel-gfx mailing list