On Thu, Apr 28, 2016 at 04:01:14PM -0700, O'Rourke, Tom wrote: > On Wed, Apr 27, 2016 at 06:10:44PM -0700, tom.orourke@xxxxxxxxx wrote: > > From: Tom O'Rourke <Tom.O'Rourke@xxxxxxxxx> > > > > SLPC (Single Loop Power Controller) is a replacement for > > some host-based power management features. The SLPC > > implemenation runs in firmware on GuC. > > > > This series has been tested with SKL guc firmware > > version 6.1. > > > > The graphics power management features in SLPC in those > > versions are called GTPERF, BALANCER, and DCC. > > > > GTPERF is a combination of DFPS (Dynamic FPS) and Turbo. > > DFPS adjusts requested graphics frequency to maintain > > target framerate. Turbo adjusts requested graphics > > frequency to maintain target GT busyness; this includes > > an adaptive boost turbo method. > > > > BALANCER adjusts balance between power budgets for IA > > and GT in power limited scenarios. BALANCER is only > > active when all display pipes are in "game" mode. > > > > DCC (Duty Cycle Control) adjusts requested graphics > > frequency and stalls guc-scheduler to maintain actual > > graphics frequency in efficient range. > > > > The v3 series can be found in the archive at > > " [PATCH v3 00/25] Add support for GuC-based SLPC" > > https://lists.freedesktop.org/archives/intel-gfx/2016-April/091771.html > > > > This v4 series incorporates feedback from internal code > > reviews for Android and Yocto projects. This series also > > drops the Broxton patches; the Broxton firmware has not > > been published yet. Broxton support can be added later > > when the Broxton firmware is available. > > > > Also, the "DO NOT MERGE" patches to enable SLPC and guc > > submission by default have been dropped. These can be > > added later after SLPC has been shown to outperform > > host-based power management; this may require a newer > > version of the GuC firmware. > > > > With SLPC disabled by default, this series should be > > safe to merge now. > > > > VIZ-6773, VIZ-6889 > > Thank you to Chris, Daniel and Imre for your comments. > I agree that some of the suggested changes should be made. > > Whether those changes should be made before merging or with > later patches will be someone else's problem. > > I won't be sending another version of this series. Thank you for the series, but if you are not willing to maintain it or at the very least bring it to the point where it can be enabled by default (and by virtue have several people familar with the hw, implementation and user interactions), why should any one else? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
