[Intel-gfx] [PATCH 1/2] drm/i915: Allocate kernel_contexts directly

[Chris Wilson]

Quoting Mika Kuoppala (2019-08-08 13:43:25)
> Chris Wilson <chris at chris-wilson.co.uk> writes:
> > @@ -1336,43 +1347,49 @@ static int __intel_engines_record_defaults(struct drm_i915_private *i915)
> >                */
> >               err = i915_vma_unbind(state);
> >               if (err)
> > -                     goto err_active;
> > +                     goto out;
> >  
> >               i915_gem_object_lock(state->obj);
> >               err = i915_gem_object_set_to_cpu_domain(state->obj, false);
> 
> Ok this has the implicit wait on it. Was confused for a moment
> that how can we fetch the state async.

There's also a global wait_for_idle just above. (I am tempted to
streamline this and run it in parallel using kworkers, but first we need
to finish refactoring the intel_gt_pm.)
 
> The path ahead that no need for global kernel context but
> engines setup their default for cloning new ones?

intel_engine_cs create their own kernel_context, which are not to be
(directly) used by userspace.

GEM context creates a fresh set of per-engine logical contexts on each
creation. (When we stop creating a i915->kernel_context, we will remove
the duplication -- but now as we never use them, we never allocate
state, so not much wastage by allocating engine->kernel_context
directly.)
 
> Can't poke holes on this. Didn't get into bottom of how the
> active tracking grabs the ce reference on pinning but
> everything stays the same on that front so was just wandering
> around in other unknown paths.

It's active references for everybody. We track context activity by
i915_active, intel_context_pin() marks it as active and our
intel_context_active callback takes a reference. intel_context_unpin()
releases the i915_active on the next idle request, at which time we call
the intel_context_retire callback and drop the reference. Thus for as
long as we suspect the HW has access to the context (i.e. pin until next
context switch) we keep the context state alive and bound.

We had to resort to such complexity because we have to treat submission
as a black box -- we cannot presume the order of execution (guc).
However, it ties it all together because we have the same sort of
problem with tracking vma and buffer activity.
-Chris