On Tue, Jan 26, 2016 at 09:17:51AM -0800, Jesse Barnes wrote: > On 01/26/2016 09:00 AM, Daniel Vetter wrote: > > On Tue, Jan 26, 2016 at 07:45:42AM -0800, Jesse Barnes wrote: > >> On 01/22/2016 09:00 AM, Daniel Vetter wrote: > >>> On Wed, Jan 20, 2016 at 06:26:02PM -0800, 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 is a first request for comments. This series > >>>> is not expected to be merged. After changes based on > >>>> comments, a later patch series will be sent for merging. > >>>> > >>>> This series has been tested with SKL guc firmware > >>>> versions 4.3 and 4.7. The graphics power management > >>>> features in SLPC in those versions are DFPS (Dynamic FPS), > >>>> Turbo, and DCC (Duty Cycle Control). DFPS adjusts > >>>> requested graphics frequency to maintain target framerate. > >>>> Turbo adjusts requested graphics frequency to maintain > >>>> target GT busyness. DCC adjusts requested graphics > >>>> frequency and stalls guc-scheduler to maintain actual > >>>> graphics frequency in efficient range. > >>> > >>> Either it's been forever long ago or I missed that meeting, so I'll drop > >>> my big arch concerns here. We probably need to discuss this internally, at > >>> least the benchmark data. Two big items: > >>> > >>> - How does GuC measure fps rendered to the screen? More specifically, how > >>> does it figure out that we missed a frame and kick the throttle up? > >> > >> Yeah, this has been covered before, both in the design review and with > >> the GuC team; I don't think the DFPS feature is ready for Linux usage > >> yet, or at least not generally, since afaik it doesn't have a way to > >> monitor offscreen rendering at all, so may end up keeping the GPU freq > >> lower than it needs to be when several clients are rendering to > >> offscreen buffers and passing them to the compositor (depending on the > >> compositor behavior at least). > > > > There's also all kinds of issues with the current design, like: > > - kernel knows when exactly we missed the vblank to display the next > > frame, guc can only control for average fps. > > > > - all the fun you mention about multiple clients. > > > > - what if we have more than 1 display running at different fps? > > Yep; I think a userspace solution with a kernel interface would do a > better job here (I outlined one a few years ago, but the lazyweb hasn't > implemented it for me yet). [TOR:] Patch 14/22 in this series sends display configuration info to SLPC. If there are multiple displays, SLPC can take that into consideration. > > > I'd say we need to keep the boost-deboost stuff alive, e.g. by manually > > telling guc that the we want different limits, then resetting those limits > > again after the boost is done. Same for fast idling - kernel simply has a > > better idea if anyone is about to submit more work (we have execbuf hints > > for specific workloads like libva). [TOR:] Could those hints be sent to GuC as well? > > > > Of course this assumes that guc slpc actually obeys our new limit requests > > fast enough, so we'd still need to benchmark to make sure it's not slower > > than what we have. > > I definitely want to see benchmarking here too. Maybe the GuC does > boosting differently, but it may be just as good as what we have for all > practical purposes. > > Jesse _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
