[igt-dev] [PATCH i-g-t v21 32/35] tests/gem_ppgtt: Adopt test to use intel_bb with allocator

[Zbigniew Kempczyński]

On Fri, Mar 05, 2021 at 03:00:09PM +0000, Chris Wilson wrote:
> Quoting Zbigniew Kempczyński (2021-03-01 16:14:00)
> > Tests work in multiprocess environment so we must turn on/off
> > thread in parent process which is responsible for allocations.
> > 
> > Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski at intel.com>
> > Cc: Dominik Grzegorzek <dominik.grzegorzek at intel.com>
> > Cc: Chris Wilson <chris at chris-wilson.co.uk>
> > ---
> >  tests/i915/gem_ppgtt.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/tests/i915/gem_ppgtt.c b/tests/i915/gem_ppgtt.c
> > index 5f8b34224..678a63498 100644
> > --- a/tests/i915/gem_ppgtt.c
> > +++ b/tests/i915/gem_ppgtt.c
> > @@ -283,10 +283,13 @@ igt_main
> >                 rcs = calloc(sizeof(*rcs), nchild);
> >                 igt_assert(rcs);
> >  
> > +               intel_allocator_multiprocess_start();
> 
> Can we use child_pid to warn when an allocator is used in a child?
> 
> But here the allocator is not shared between children, as each child
> will have their own set of ppGTT to play with.
> 
> What am I missing?
> -Chris

For forking we have two scenarios:

1. child wants to connect to parent infrastructure (default). Allows
   sharing <fd, ctx> as well as uses its own <fd2, ctx2>, thus having
   its own vm. gem_ppgtt is such case - we got single allocator 
   infrastructure but children can access it with unique <fd, ctx> key.
   Only drawback is we use some communication channel instead of 
   direct allocation.

2. child wants to unconnect from parent infrastructure, so it likely
   should call intel_allocator_init() to prepare data structures 
   within its memory. intel_allocator_init() doesn't call channel->init()
   so allocator should be "standalone" for such child (subsequent
   forks are not allowed, IGT doesn't allow to do igt_fork within
   igt_fork if I'm not wrong). I didn't test such scenario so it is
   good idea for test, I'm going to add this in api_intel_allocator.

Only case which is problematic is:

fd = drm_open_driver(DRIVER_INTEL);
igt_fork(child, 1) {
	close(fd);
	fd = drm_open_driver(DRIVER_INTEL);
	...
}

In this case allocator is not aware fd is same but i915 instance differs.
So allocations for <fd, ctx> in parent/child is from allocator perspective
same, but for kernel is not.

--
Zbigniew