[Intel-gfx] [PATCH 01/23] drm/i915: Move aliasing_ppgtt underneath its i915_ggtt

Chris Wilson chris at chris-wilson.co.uk
Wed Jul 24 09:27:38 UTC 2019


Quoting Tvrtko Ursulin (2019-07-24 09:56:34)
> 
> On 23/07/2019 19:38, Chris Wilson wrote:
> > The aliasing_ppgtt provides a PIN_USER alias for the global gtt, so move
> > it under the i915_ggtt to simplify later transformations to enable
> > intel_context.vm.
> 
> Can you pin point what exactly it makes easier in the following patch? 
> Just the __context_pin_ppgtt change? I have reservations about ggtt 
> embedding aliasing ppgtt. But I guess it is handy for some usages.

The aliasing_ggtt is an adjunct of i915_ggtt. Conceptually, we replace
the ggtt with one that has both global and user tracking with a reserved
slice for the aliasing pd. It should be a function of gt not mm, and it
purely an extension of our ggtt.

For aliasing [gen6] user contexts, our address space refers to the
i915_ggtt, but we must write our entries (for the most part) into the
alias. Having ce->vm always pointing to the correct gtt has been high on
the wish list for about 6 years, it just never fell into place. This I
feel is the missing link.

> > +static struct i915_address_space *vm_alias(struct intel_context *ce)
> > +{
> > +     struct i915_address_space *vm;
> > +
> > +     vm = ce->gem_context->vm;
> > +     if (!vm)
> > +             vm = &ce->engine->gt->ggtt->alias->vm;
> > +
> > +     return vm;
> 
> vm_or_alias? Still not good.. get_vm might pass since it is local?

vm is a perfectly acceptable alias for itself. I prefer vm_alias() as I
think it makes it clearer that we are principally concerned with the
PIN_USER aspect of the gtt.

> > +}
> > +
> > +static int __context_pin_ppgtt(struct intel_context *ce)
> >   {
> >       struct i915_address_space *vm;
> >       int err = 0;
> >   
> > -     vm = ctx->vm ?: &ctx->i915->mm.aliasing_ppgtt->vm;
> > +     vm = vm_alias(ce);
> >       if (vm)
> 
> Can't return NULL it seems. (Same below.)

Are you so sure?

ce->gem_context->vm is only !NULL if there is a full-ppgtt
&ggtt->alias->vm is only !NULL if there is an aliasing-ppgtt

There may be contexts with neither (gen4, gen5).

> > @@ -1701,7 +1712,7 @@ static inline int mi_set_context(struct i915_request *rq, u32 flags)
> >       return 0;
> >   }
> >   
> > -static int remap_l3(struct i915_request *rq, int slice)
> > +static int remap_l3_slice(struct i915_request *rq, int slice)
> >   {
> >       u32 *cs, *remap_info = rq->i915->l3_parity.remap_info[slice];
> >       int i;
> > @@ -1729,15 +1740,34 @@ static int remap_l3(struct i915_request *rq, int slice)
> >       return 0;
> >   }
> >   
> > +static int remap_l3(struct i915_request *rq)
> > +{
> > +     struct i915_gem_context *ctx = rq->gem_context;
> > +     int i, err;
> > +
> > +     if (!ctx->remap_slice)
> > +             return 0;
> > +
> > +     for (i = 0; i < MAX_L3_SLICES; i++) {
> 
> err declaration could go here but meh..
> 
> > +             if (!(ctx->remap_slice & BIT(i)))
> > +                     continue;
> > +
> > +             err = remap_l3_slice(rq, i);
> > +             if (err)
> > +                     return err;
> 
> ... or could stay at top and here you break and return err at the end. 
> More meh. Depending whether it is important or not to clear 
> ctx->remap_slice on error.

We don't want to clear remap_slice on error as we haven't applied it and
should try again on the next attempted request.

> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index 4dd1fa956143..8304b98b0bf8 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -2446,18 +2446,18 @@ static int aliasing_gtt_bind_vma(struct i915_vma *vma,
> >               pte_flags |= PTE_READ_ONLY;
> >   
> >       if (flags & I915_VMA_LOCAL_BIND) {
> > -             struct i915_ppgtt *appgtt = i915->mm.aliasing_ppgtt;
> > +             struct i915_ppgtt *alias = i915_vm_to_ggtt(vma->vm)->alias;
> 
> Keeping the variable name would have reduced the churn.

I went for consistency with the more succinct name.
-Chris


More information about the Intel-gfx mailing list