Quoting Ville Syrjälä (2018-07-06 15:47:25)
> On Fri, Jul 06, 2018 at 03:23:22PM +0100, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_coherency.c b/drivers/gpu/drm/i915/selftests/i915_gem_coherency.c
> > index cb9eef1635e1..294c58aba2c1 100644
> > --- a/drivers/gpu/drm/i915/selftests/i915_gem_coherency.c
> > +++ b/drivers/gpu/drm/i915/selftests/i915_gem_coherency.c
> > @@ -210,12 +210,12 @@ static int gpu_set(struct drm_i915_gem_object *obj,
> > *cs++ = upper_32_bits(i915_ggtt_offset(vma) + offset);
> > *cs++ = v;
>
> Missed the gen8+ case here?
>
> > } else if (INTEL_GEN(i915) >= 4) {
> > - *cs++ = MI_STORE_DWORD_IMM_GEN4 | 1 << 22;
> > + *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
>
> So here we use ggtt on all gens. In the other tests we use ppgtt on
> gen6+. Ah, this one uses the kernel context apparently. I guess that's
> the reason?
If memory serves, yes, this was deliberately trying to use the ppGTT in
this case. I guess I need to check this against the full-ppgtt patches
for gen7 (although shard-hsw didn't flag anything iirc), but this should
probably have a (gen < 6 ? MI_USE_GGTT : 0) here.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
