[Intel-gfx] [RFC] Hack to avoid C-state reduction during graphics activity.
luto at mit.edu
Mon Nov 1 14:00:46 PDT 2010
Out of curiousity, what happened to ACPI_BM_BREAK_EN here:
On my box, that register is (according to setpci) 0x00, but I'm
testing on an ICH9M and I don't seem to be affected anyway.
On Mon, Nov 1, 2010 at 4:23 PM, Eric Anholt <eric at anholt.net> wrote:
> This is a series I came up with as a result of KS discussions. The
> plan was to pin the CPU C state to keep the GPU going as fast as
> possible while it was active, since there's some relation between the
> two (we don't know for sure yet, per chipset, whether it's due to
> latency of DMA writes having to bring CPU state up, or reduced memory
> bandwidth due to bus frequency reduction, or other). The actual patch
> series doesn't achieve that -- a hint is provided to the scheduler and
> cpufreq/cpuidle, which may choose not to sleep as deeply as it would
> I found a 1% performance difference in nexuiz on my Ironlake system
> from the last patch in this series (HEAD~1 didn't have a statistically
> significant effect). If that's all the difference, I'll drop this.
> It may pay off higher for non-Ironlake, in which case I'll work on a
> "proper" solution of actually clamping C-states while graphics is
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
More information about the Intel-gfx