[Intel-gfx] [RESEND] drm/i915: Interactive RPS mode
Chris Wilson
chris at chris-wilson.co.uk
Sat Jul 21 08:44:12 UTC 2018
Quoting Ville Syrjälä (2018-07-20 15:19:20)
> On Fri, Jul 20, 2018 at 03:03:09PM +0100, Chris Wilson wrote:
> > Quoting Ville Syrjälä (2018-07-20 14:50:25)
> > > On Fri, Jul 20, 2018 at 02:38:32PM +0100, Chris Wilson wrote:
> > > > Quoting Ville Syrjälä (2018-07-20 14:32:40)
> > > > > Another question is what happens where there are parallel flips
> > > > > happening? One could undo the boost from the other AFAICS. But maybe
> > > > > we don't care enough to protect against that?
> > > >
> > > > It's a counter, so the "interactive" mode remains high until all
> > > > concurrent flips are completed.
> > >
> > > Ah. I guess the bool in the atomic state threw me off. I suppose that
> > > one is just an optimization to avoid calling the function more than
> > > once?
> >
> > Yes, it's that I caught the RPS counter going negative. We have more
> > cleanup_plane than we prepared.... I believe that's from
> > find_initial_plane.
>
> Hmm. I don't quite see how that could happen. I believe
> prepare_fb/cleanup_fb should be fully paired up within a single commit.
The way I read intel_find_initial_plane_obj() is that it writes the
current configuration into the current intel_crtc->base.primary->state.
I think that is where the initial mismatch comes from. Also we seem to
be quite adapt at not holding rps_interactive high after modeset
completion, which suggests to me that something sneaky is happening with
the plane_state duplication.
-Chris
More information about the Intel-gfx
mailing list