Quoting Michał Winiarski (2017-09-20 11:48:54)
> On Tue, Sep 19, 2017 at 01:21:08PM +0100, Chris Wilson wrote:
> > Quoting Chris Wilson (2017-09-07 15:30:55)
> > > We don't expect every machine to be able to pass the WC/GTT coherency
> > > check, see
> > >
> > > kernel commit 3b5724d702ef24ee41ca008a1fab1cf94f3d31b5
> > > Author: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > > Date: Thu Aug 18 17:16:49 2016 +0100
> > >
> > > drm/i915: Wait for writes through the GTT to land before reading back
> > >
> > > If we quickly switch from writing through the GTT to a read of the
> > > physical page directly with the CPU (e.g. performing relocations through
> > > the GTT and then running the command parser), we can observe that the
> > > writes are not visible to the CPU. It is not a coherency problem, as
> > > extensive investigations with clflush have demonstrated, but a mere
> > > timing issue - we have to wait for the GTT to complete it's write before
> > > we start our read from the CPU.
> > >
> > > The issue can be illustrated in userspace with:
> > >
> > > gtt = gem_mmap__gtt(fd, handle, 0, OBJECT_SIZE, PROT_READ | PROT_WRITE);
> > > cpu = gem_mmap__cpu(fd, handle, 0, OBJECT_SIZE, PROT_READ | PROT_WRITE);
> > > gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
> > >
> > > for (i = 0; i < OBJECT_SIZE / 64; i++) {
> > > int x = 16*i + (i%16);
> > > gtt[x] = i;
> > > clflush(&cpu[x], sizeof(cpu[x]));
> > > assert(cpu[x] == i);
> > > }
> > >
> > > Experimenting with that shows that this behaviour is indeed limited to
> > > recent Atom-class hardware.
> > >
> > > so split out the interleave coherency check from the basic
> > > interopability check.
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102577
> > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> >
> > Ping?
>
> Mechanical change. LGTM.
> One question though - if we do expect that coherency-gtt may fail on low-power
> HW, perhaps we should skip it there, rather than filter through the noisy
> results?
I don't know for sure; the test is a good discriminator for which
platforms do need extra care (and so far big core seems reliable).
> OTOH, determining test behaviour based on particular "device id" (generation
> really), rather than some "capability" is kind of ugly.
Yup. And such knowledge should flow from the kernel "hey, on this
platform this ABI expectation can no longer be met".
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
