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