| Message ID | 20191126142548.22696-1-janusz.krzysztofik@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC,i-g-t] tests/prime_vgem: Skip MMAP_GTT based subtests if no mappable GGTT | expand |
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@ffwll.ch> > Cc: Joonas Lahtinen <joonas.lahtinen@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. -Chris
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@ffwll.ch> > > Cc: Joonas Lahtinen <joonas.lahtinen@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. OK, I'll try to add these alternatives. Thanks, Janusz > -Chris >
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@ffwll.ch> > > Cc: Joonas Lahtinen <joonas.lahtinen@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 >
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)); scratch.width = 1024;