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). > 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). > > 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
