Quoting Chris Wilson (2018-05-03 10:36:59) > Investigating the coherency issue on gdg (ye olde gen2), in particular > the failure in gem_set_tiling_vs_pwrite, it appears that gem_write() > followed by gem_read() fails. That is a write through the GTT write > domain, followed by a read through the CPU domain. Since we have > disabled clflush on the machine, we know it is moving the whole object > between domains and issuing wbinvd. Still this does not appear to be > enough, so let's resort to a chipset-flush which includes poking around > in magic registers. > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > --- > drivers/gpu/drm/i915/i915_gem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 484354f25f98..e97aacc335f2 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -793,7 +793,7 @@ void i915_gem_flush_ggtt_writes(struct drm_i915_private *dev_priv) > * that was!). > */ > > - wmb(); > + i915_gem_chipset_flush(dev_priv); > > intel_runtime_pm_get(dev_priv); > spin_lock_irq(&dev_priv->uncore.lock); I should mention that we should do a better job of tracking when we need such a global hammer -- we almost have the infrastructure in place as we do track GGTT writes on a vma, we just don't keep them in a global list. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
