Yeah if that works we could definitely add some qos calls to the driver. When vblanks are alive we'd need a latency less tha the refresh rate, and when commands are oustanding we'd probably want it even lower.
Vasily, can you try the qos workaround on your machine and see if it works too? Thanks, "Simon Farnsworth" <simon.farnswo...@onelan.co.uk> wrote: >On Thursday 16 September 2010, Vasily Khoruzhick <anars...@gmail.com> wrote: >> В сообщении от 15 of September 2010 01:41:11 автор Sitsofe Wheeler написал: >> > > > processor.max_cstate=2 >> > > >> > > Nope, it doesn't work with max_cstate=2 >> > >> > Perhaps intel_idle is being used? Any mention of it in dmesg? >> >> Sitsofe, maybe you misunderstood me, I mean with max_cstate=1 graphics is >> smooth, with higher values (i.e. max_cstate=2) graphics is jerky. >> >> Btw, Jesse, any comments/solutions/workarounds except one with >> processor.max_cstate=1 in kernel commandline? Should I file a bug on fdo >> bugzilla? > >This looks like a problem I've seen on some hardware. > >My workaround has been to use the pm_qos /dev/cpu_dma_latency interface to >request a maximum latency of 1ms (value chosen as definitely small enough - a >larger value may be better, but I don't care about power saving at runtime on >my kit). > >If it's happening on other kit, perhaps the i915 driver should make a suitable >pm_qos request itself. Jesse, can you comment? >-- >Simon Farnsworth >Software Engineer >ONELAN Limited >http://www.onelan.com/ > -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
