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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux