On Mon, Jul 16, 2012 at 12:50 PM, Daniel Vetter <daniel at ffwll.ch> wrote: > On Wed, Jul 04, 2012 at 09:52:11AM +0200, Daniel Vetter wrote: > > On Tue, Jul 03, 2012 at 02:16:42PM -0700, St?phane Marchesin wrote: > > > The up and down thresholds are very asymetric, so it is possible > > > to have a case where a spike of rendering increases the GPU clock to > > > the max (because the up threshold is low) and then a simple blinking > > > cursor is enough to keep the clock at the maximum speed forever > > > (because the down threshold is high). > > > > > > Lowering the down threshold allows the GPU clock to go back down even > > > when there is a blinking cursor on the screen. > > > > > > Signed-off-by: St?phane Marchesin <marcheu at chromium.org> > > > > I've just merged Eugeni's hsw rc6 patches - those contain newly tuning > > variables. Can you maybe try out whether these would have the same > effect? > > I'd prefer to simple enable these, presuming that the hw guys we've got > > them from did some decent tuning ... > > Ping. > > 3.6 merge window is approach fast and I think I'd be good to get this in > ... Or something similar, based on the hsw ratio between downclock and > upclock limit, but with the slightly bigger thresholds used by ivb/snb for > upclocks maybe? > So now that the dust settled, and that we better understand what's going on, I am sure that those values are not adequate for us (neither the default SNB/IVB, nor the Haswell ones). For the record, here is what we set differently for Chrome OS to solve our issues (we didn't see a performance regression, but we do get a major power consumption reduction for lighter GPU loads like playing a video and that blinking cursor): GEN6_RP_DOWN_TIMEOUT 10000 GEN6_RP_UP_THRESHOLD 0x4000 GEN6_RP_DOWN_THRESHOLD 0x4000 St?phane -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120815/719b6bf1/attachment.html>
