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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
