[Intel-gfx] [PATCH 8/8] drm/i915: Pipeline PDP updates for Braswell

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-12-04 11:53:22)
> 
> On 03/12/2018 11:37, Chris Wilson wrote:
> > Currently we face a severe problem on Braswell that manifests as invalid
> > ppGTT accesses. The code tries to maintain the PDP (page directory
> > pointers) inside the context in two ways, direct write into the context
> > and a pipelined LRI update. The direct write into the context is
> > fundamentally racy as it is unserialised with any access (read or write)
> > the GPU is doing. By asserting that Braswell is not used with vGPU
> > (currently an unsupported platform) we can eliminate the dangerous
> > direct write into the context image and solely use the pipelined update.
> > 
> > However, the LRI of the PDP fouls up the GPU, causing it to freeze and
> > take out the machine with "forcewake ack timeouts". This seems possible
> > to workaround by preventing the GPU from sleeping (via means of
> > disabling the power-state management interface, i.e. forcing each ring
> > to remain awake) around the update.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108656
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=108714
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> > ---
> > diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> > index ca95ab2f4cfa..8ab8e8e6a086 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -719,11 +719,6 @@ i915_request_alloc(struct intel_engine_cs *engine, struct i915_gem_context *ctx)
> >        */
> >       rq->head = rq->ring->emit;
> >   
> > -     /* Unconditionally invalidate GPU caches and TLBs. */
> > -     ret = engine->emit_flush(rq, EMIT_INVALIDATE);
> 
> It seems this is still always called at least once on the common path so 
> why are you moving it to the backend? Just because it is more "backendy" 
> type operation? It makes sense I guess.

Yup. Having gone through many iterations, not all quite as symmetrical
as the current incarnation, specialisation of flushes to the backend
made sense. We pulled it into the core because everyone had to do their
invalidate first, but that might not actually be so true (at least, we
probably should do the invalidate after the context load in ringbuffer,
but one bug at a time).

> > +static int emit_pdps(struct i915_request *rq)
> > +{
> > +     const struct intel_engine_cs * const engine = rq->engine;
> > +     struct i915_hw_ppgtt * const ppgtt = rq->gem_context->ppgtt;
> > +     int err, i;
> > +     u32 *cs;
> > +
> > +     err = engine->emit_flush(rq, EMIT_INVALIDATE);
> > +     if (err)
> > +             return err;
> > +
> > +     cs = intel_ring_begin(rq, 4 * GEN8_3LVL_PDPES + 2);
> > +     if (IS_ERR(cs))
> > +             return PTR_ERR(cs);
> > +
> > +     /*
> > +      * Force the GPU (not just the local engine/powerwell!) to remain awake,
> > +      * or else we may kill the machine with "timed out waiting for
> > +      * forcewake ack request".
> > +      */
> > +
> > +     *cs++ = MI_LOAD_REGISTER_IMM(2 * GEN8_3LVL_PDPES) | MI_LRI_FORCE_POSTED;
> > +     for (i = GEN8_3LVL_PDPES; i--; ) {
> > +             const dma_addr_t pd_daddr = i915_page_dir_dma_addr(ppgtt, i);
> > +
> > +             *cs++ = i915_mmio_reg_offset(GEN8_RING_PDP_UDW(engine, i));
> > +             *cs++ = upper_32_bits(pd_daddr);
> > +             *cs++ = i915_mmio_reg_offset(GEN8_RING_PDP_LDW(engine, i));
> > +             *cs++ = lower_32_bits(pd_daddr);
> > +     }
> > +     *cs++ = MI_NOOP;
> > +
> > +     intel_ring_advance(rq, cs);
> > +
> > +     err = engine->emit_flush(rq, EMIT_INVALIDATE);
> > +     if (err)
> > +             return err;
> > +
> > +     return 0;
> > +}
> > +
> >   static int execlists_request_alloc(struct i915_request *request)
> >   {
> >       int ret;
> >   
> >       GEM_BUG_ON(!request->hw_context->pin_count);
> >   
> > -     /* Flush enough space to reduce the likelihood of waiting after
> > +     /*
> > +      * Flush enough space to reduce the likelihood of waiting after
> >        * we start building the request - in which case we will just
> >        * have to repeat work.
> >        */
> >       request->reserved_space += EXECLISTS_REQUEST_SIZE;
> >   
> > -     ret = intel_ring_wait_for_space(request->ring, request->reserved_space);
> > -     if (ret)
> > -             return ret;
> 
> Removing this in favour of what intel_ring_begin will do? But is it the 
> same? Could be.. just not sure due all the arithmetic that's happening 
> in these areas..

It's the same effect. intel_ring_wait_for_space() was just a shorthand
to avoid the secondary effect of preparing the ring for the request.

> > -
> > -     /* Note that after this point, we have committed to using
> > +     /*
> > +      * Note that after this point, we have committed to using
> >        * this request as it is being used to both track the
> >        * state of engine initialisation and liveness of the
> >        * golden renderstate above. Think twice before you try
> >        * to cancel/unwind this request now.
> >        */
> >   
> > +     /* Unconditionally invalidate GPU caches and TLBs. */
> > +     if (i915_vm_is_48bit(&request->gem_context->ppgtt->vm)) {
> > +             ret = request->engine->emit_flush(request, EMIT_INVALIDATE);
> 
> Excuse my ignorance, but what is the PDP update mechanism in 48-bit mode?

The top-most level is fixed (i.e. the address register inside the context
image for the pm4l page), and the TLBs flushed by EMIT_INVALIDATE. Each
batch then traverses the new page directory tree afresh.

> > +             if (ret)
> > +                     return ret;
> > +     } else {
> > +             GEM_BUG_ON(intel_vgpu_active(request->i915));
> > +             ret = emit_pdps(request);
> > +             if (ret)
> > +                     return ret;
> > +     }
> > +
> 
> There is always a starting EMIT_INVALIDATE on both of these two branches 
> so you could pull it out before the if block.

Still playing. Though at the moment, it's 8 EMIT_FLUSH after the LRI. My
point is that the emit_pdps() is decidedly a magic sequence, dropping
that EMIT_INVALIDATE (in favour of just one after) causes "media forcewake
errors". I should probably have a much bigger "here be unknown dragons".

> >   static int gen8_emit_bb_start(struct i915_request *rq,
> >                             u64 offset, u32 len,
> >                             const unsigned int flags)
> >   {
> >       u32 *cs;
> > -     int ret;
> > -
> > -     /* Don't rely in hw updating PDPs, specially in lite-restore.
> > -      * Ideally, we should set Force PD Restore in ctx descriptor,
> > -      * but we can't. Force Restore would be a second option, but
> > -      * it is unsafe in case of lite-restore (because the ctx is
> > -      * not idle). PML4 is allocated during ppgtt init so this is
> > -      * not needed in 48-bit.*/
> > -     if ((intel_engine_flag(rq->engine) & rq->gem_context->ppgtt->pd_dirty_rings) &&
> > -         !i915_vm_is_48bit(&rq->gem_context->ppgtt->vm) &&
> > -         !intel_vgpu_active(rq->i915)) {
> > -             ret = intel_logical_ring_emit_pdps(rq);
> 
> What is the reason to move from emit_bb_start to request_alloc?

Long standing pet peeve. Imho, this is not about the BB_START but is an
integral part of TLB invalidation. So inappropriate misuse of
emit_bb_start.
-Chris