Quoting Joonas Lahtinen (2018-11-20 09:48:36)
> Quoting Chris Wilson (2018-11-19 17:41:53)
> > Under moderate amounts of GPU stress, we can observe on Bearlake and
> > Pineview (later gen3 models) that we execute the following batch buffer
> > before the write into the batch is coherent. Adding extra (tested with
> > upto 32x) MI_FLUSH to either the invalidation, flush or both phases does
> > not solve the incoherency issue with the relocations, but emitting the
> > MI_STORE_DWORD_IMM twice does. So be it.
> >
> > Fixes: 7dd4f6729f92 ("drm/i915: Async GPU relocation processing")
> > Testcase: igt/gem_tiled_fence_blits # blb/pnv
> > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
>
> <SNIP>
>
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -1268,7 +1268,7 @@ relocate_entry(struct i915_vma *vma,
> > else if (gen >= 4)
> > len = 4;
> > else
> > - len = 3;
> > + len = 6;
> >
> > batch = reloc_gpu(eb, vma, len);
> > if (IS_ERR(batch))
> > @@ -1309,6 +1309,11 @@ relocate_entry(struct i915_vma *vma,
> > *batch++ = MI_STORE_DWORD_IMM | MI_MEM_VIRTUAL;
> > *batch++ = addr;
> > *batch++ = target_offset;
> > +
> > + /* And again for good measure (blb/pnv) */
> > + *batch++ = MI_STORE_DWORD_IMM | MI_MEM_VIRTUAL;
> > + *batch++ = addr;
> > + *batch++ = target_offset;
>
> I guess you already balanced between for() loop and this, maybe this is
> clearer.
Given c99 for-loops, it would be a no brainer. It's a wart, it should be
ugly!
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
