[Intel-gfx] [PATCH igt] igt/prime_mmap_coherency: Call prime_sync_start before read after write
Chris Wilson
chris at chris-wilson.co.uk
Wed Oct 18 15:04:43 UTC 2017
Quoting Daniel Vetter (2017-10-18 15:47:27)
> On Wed, Oct 18, 2017 at 03:19:44PM +0100, Chris Wilson wrote:
> > We never declared that we were about to read from the mmap after copying
> > into using the BLT (a missed call to prime_sync_start); leaving its
> > coherency ill-defined. For completeness, add the missing
> > prime_sync_end() as well.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103168
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > ---
> > tests/prime_mmap_coherency.c | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/tests/prime_mmap_coherency.c b/tests/prime_mmap_coherency.c
> > index a213ac0f..064c61a7 100644
> > --- a/tests/prime_mmap_coherency.c
> > +++ b/tests/prime_mmap_coherency.c
> > @@ -98,6 +98,8 @@ static int test_read_flush(void)
> > if (ptr_cpu[i] != 0xc5c5c5c5)
> > stale++;
>
> Shouldn't we add a prime_sync_start/end for the first ptr_cpu access too?
> Just for over-the-top correctness?
The loop where we check the new buffer is zero? Yup, missed that.
That works as an interesting check with the mmap held across the blt,
with sync's before/after.
I suppose as we repeat the test several times, in addition to different
bit values, we should also try different patterns of blts. Another day.
-Chris
More information about the Intel-gfx
mailing list