[Intel-gfx] [RFC] Hack to avoid C-state reduction during graphics activity.

[Andrew Lutomirski]

Out of curiousity, what happened to ACPI_BM_BREAK_EN here:

https://bugs.freedesktop.org/show_bug.cgi?id=30364

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.

--Andy



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
> otherwise.
>
> 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
> active.
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>