[Intel-gfx] [RFC PATCH i-g-t] tests/prime_vgem: Skip MMAP_GTT based subtests if no mappable GGTT

[Janusz Krzysztofik]

Hi Chris,

On Tuesday, November 26, 2019 3:34:13 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-11-26 14:25:48)
> > As we've agreed that using GEM_MMAP* IOCTLs on dma-buf objects without
> > a CPU accessible GART is very questionable, we are probably not going
> > to extend our MMAP_OFFSET handler with an extra processing path
> > required for it to work correctly on dma-buf objects.  As a
> > consequence, on future hardware with no mappable aperture we won't be
> > able to use MMAP_OFFSET as a replacement of MMAP_GTT in tests which
> > examine PRIME import interface.  When running on that kind of hardware,
> > just skip subtests which depend on gem_mmap__gtt().
> > 
> > Cc: Daniel Vetter <daniel at ffwll.ch>
> > Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> > ---
> >  tests/prime_vgem.c | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/tests/prime_vgem.c b/tests/prime_vgem.c
> > index 04cc913d..b92cf4f7 100644
> > --- a/tests/prime_vgem.c
> > +++ b/tests/prime_vgem.c
> > @@ -126,6 +126,8 @@ static void test_fence_mmap(int i915, int vgem)
> >         int dmabuf, i;
> >         int master[2], slave[2];
> >  
> > +       gem_require_mappable_ggtt(i915);
> > +
> >         igt_assert(pipe(master) == 0);
> >         igt_assert(pipe(slave) == 0);
> >  
> > @@ -210,6 +212,8 @@ static void test_gtt(int vgem, int i915)
> >         uint32_t *ptr;
> >         int dmabuf, i;
> >  
> > +       gem_require_mappable_ggtt(i915);
> > +
> >         scratch.width = 1024;
> >         scratch.height = 1024;
> >         scratch.bpp = 32;
> > @@ -285,6 +289,7 @@ static void test_gtt_interleaved(int vgem, int i915)
> >         uint32_t *ptr, *gtt;
> >         int dmabuf, i;
> >  
> > +       gem_require_mappable_ggtt(i915);
> >         igt_require(is_coherent(i915));
> 
> Ok, but these (fence_mmap, gtt_interleaved) want WC coherency as an 
alternative.
> test_gtt probably wants a basic test_wc alternative.

I've been thinking about that and my conclusion is that with no mappable 
aperture on board, it's no longer possible to access the imported object data, 
or at least arrange for such access, using i915 KMD interface, unless we 
extend the upcoming MMAP_OFFSET with a redirection to dma-buf interface.  
Based on some comments from Joonas and Daniel I received in response to my 
attempts to add such support, I'm assuming we are not going to do that.

Without that, the only possibility I can see for userspace to access those 
data is to use mmap on the dma-buf file descriptor directly, completely 
bypassing i915 and its PRIME import function.

Then, assuming the prime_vgem test is about testing just the PRIME import 
function of a driver, we have no alternative to MMAP_GTT to test here, I 
believe, unless we are going to test dma-buf interface over vgem driver PRIME 
export function, not the i915 KMD ABI.  Just skipping the tests that require 
unsupported i915 functionality (mappable aperture) seems a reasonable approach 
to me.

Thanks,
Janusz


> -Chris
>