[Intel-gfx] [PATCH 2/2] drm/i915: Serialise updates to GGTT with access through GGTT on Braswell

Chris Wilson chris at chris-wilson.co.uk
Fri Oct 23 12:45:39 PDT 2015

On Fri, Oct 23, 2015 at 06:43:32PM +0100, Chris Wilson wrote:
> (I have not looked for any pattern such
> as modifying PTE within the same page or cacheline as active PTE -
> though checking whether revoking neighbouring objects should be enough
> to test that theory.)

So, fwiw, I revoked the CPU PTE for the neighbouring objects (each object
is 1MiB in size and so should occupy 2KiB in the GGTT) but the
corruption persisted. If I didn't make a mistake that should squash the
theory that it is access through PTE neighbouring the update that are
trampled upon. I had also earlier ioremaped the GGTT (dev_priv->gtt.gsm)
as uncached, and thrown countless mb() around to rule out incomplete
writes to the GGTT prior to CPU access. I haven't tried idling the GPU,
as other tests within gem_concurrent_blit demonstrate that is not a GPU
flushing issue.

Chris Wilson, Intel Open Source Technology Centre

More information about the Intel-gfx mailing list