[Intel-gfx] [RESEND] drm/i915: Interactive RPS mode

Ville Syrjälä ville.syrjala at linux.intel.com
Fri Jul 20 13:07:31 UTC 2018


On Fri, Jul 20, 2018 at 02:02:34PM +0100, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-07-20 13:49:09)
> > 
> > On 12/07/2018 18:38, Chris Wilson wrote:
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > > index 7998e70a3174..5809366ff9f0 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -13104,6 +13104,19 @@ intel_prepare_plane_fb(struct drm_plane *plane,
> > >               add_rps_boost_after_vblank(new_state->crtc, new_state->fence);
> > >       }
> > >   
> > > +     /*
> > > +      * We declare pageflips to be interactive and so merit a small bias
> > > +      * towards upclocking to deliver the frame on time. By only changing
> > > +      * the RPS thresholds to sample more regularly and aim for higher
> > > +      * clocks we can hopefully deliver low power workloads (like kodi)
> > > +      * that are not quite steady state without resorting to forcing
> > > +      * maximum clocks following a vblank miss (see do_rps_boost()).
> > > +      */
> > > +     if (!intel_state->rps_interactive) {
> > > +             intel_rps_set_interactive(dev_priv, true);
> > > +             intel_state->rps_interactive = true;
> > > +     }
> > > +
> > >       return 0;
> > >   }
> > >   
> > > @@ -13120,8 +13133,15 @@ void
> > >   intel_cleanup_plane_fb(struct drm_plane *plane,
> > >                      struct drm_plane_state *old_state)
> > >   {
> > > +     struct intel_atomic_state *intel_state =
> > > +             to_intel_atomic_state(old_state->state);
> > >       struct drm_i915_private *dev_priv = to_i915(plane->dev);
> > >   
> > > +     if (intel_state->rps_interactive) {
> > > +             intel_rps_set_interactive(dev_priv, false);
> > > +             intel_state->rps_interactive = false;
> > > +     }
> > 
> > Why is the rps_intearctive flag needed in plane state? I wanted to 
> > assume prepare & cleanup hooks are fully symmetric, but this flags makes 
> > me unsure. A reviewer with more display knowledge will be needed here I 
> > think.
> 
> It's so that when we call intel_cleanup_plane_fb() on something that
> wasn't first prepared, we don't decrement the counter. There's a little
> bit of asymmetry at the start where we inherit the plane state.

Doing this kind of global thing from the plane hooks seems a bit
strange. How about just doing this directly from commit_tail()
etc.?

-- 
Ville Syrjälä
Intel


More information about the Intel-gfx mailing list