Re: [PATCH 0/5] drm/i915: Optimize plane updates a bit

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Thu, Mar 09, 2017 at 04:56:23PM +0100, Maarten Lankhorst wrote:
> Hey,
> 
> Op 09-03-17 om 16:44 schreef ville.syrjala@linux.intel.com:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Now that commit e1edbd44e23b ("drm/i915: Complain if we take too
> > long under vblank evasion.") has expose just how badly we suck,
> > it seems like a good time to optimize things a little bit.
> >
> > Prior to this one of my VLV machines exceed the 100 usec vblank
> > evade deadline pretty regularly, and at ever boot I was hitting
> > numbers as high as 500 usec. Granted that was with lockdep and
> > all kinds of other debug things enabled. After these changes
> > things seem stay below the 33 usec mark, and with all that debug
> > junk enabled we seem to staying below 22 usec.
> >
> > Note that I was testing single plane updates mostly, so I'm
> > not 100% sure multi plane updates couldn't still exceed the
> > deadline. That will need to be checked.
> I've considered doing the same before, but thanks to the commit it's clear that it seems to worth the effort to do so.
> Maybe a bit more radical, but could we grab the uncore lock for the entire update perhaps if it's still an issue?

Yes that might be the ultimate goal. One of the problems is that we
don't use pipe_update_start()/end() everywhere we do plane updates. Some
of those we need to fix (eg. crtc disable really should disable things
atomically). The "disable all extra planes at driver load time" case
I'd like to eliminate by having proper state readout/takeover for
planes. And then there's the legacy cursor thing. I guess we could
avoid bigger surgery by simply grabbing the lock manually around the
update_plane/disable_plane call in those places.

Another thing I'd like to figure out is how much are we wasting CPU
cycles for computing  the register values in the .update_plane() hooks.
If it's at all significant we should probably try to move absolutely
everything but the register writes out from those functions.

Oh, and we might even try to take advantage of the hardware's limite
atomic capabilities and only write the absolute minimum set of registers
under the vblank evasion (ie. just the ones that actually arm the
update to occur on the next vblank). Unfortunately the split between
the two classes of registers isn't all that clear. It would also make
it impossible to do the fps>vrefresh thing.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx