[Intel-gfx] FPS performance increase when deliberately spinning the CPU with an unrelated task
eric at anholt.net
Mon Oct 25 22:14:19 CEST 2010
On Sat, 23 Oct 2010 13:02:35 +0100, Peter Clifton <pcjc2 at cam.ac.uk> wrote:
> Hi guys,
> This is something I've noted before, and I think Keith P replied with
> some idea of what might be causing it, but I can't recall exactly. I
> just thought I'd mention it again in case it struck a chord with anyone.
> I'm running my app here, which is on a benchmark test, banging out
> frames as fast as the poor thing can manage. It is not CPU bound (it is
> using about 50% CPU).
> I'm getting 12 fps.
> Now I run a devious little test app, "loop", in parallel:
> int main( int argc, char **argv )
> while (1);
> Re-run the benchmark and I get 19.2 fps. (NICE).
> I suspect cpufreq scaling, so I swapped the ondemand governor for
> pcjc2 at pcjc2lap:/sys/devices/system/cpu/cpu1/cpufreq$ cat scaling_available_frequencies
> 2401000 2400000 1600000 800000
> and I only get:
> sudo cat cpuinfo_cur_freq
> (Never mind)
> Repeat setting for other core of Core2 Duo.
> Now, without my "loop" program running, I get 17.6 fps right off.
> WITH my "loop" program running, I get 18.2 fps.
> I think Keith was thinking that there are some parts of the chipset
> which are shared between the GPU and CPU (memory controllers?), and the
> CPU entering a lower frequency state could have a detrimental effect on
> the graphics throughput.
> I know in heavy workloads the CPU is likely to be "a bit" busy, and
> rendering will not be totally GPU bound, but it would seem like it is
> eventually necessary to have some hook to bump the CPU frequency (or
> chipset frequency?) when the GPU would make beneficial use of the extra
> This doesn't make sense if it is banging out 100fps, but for my stuff,
> the GPU is struggling to make 5fps for some complex circuit boards. I'm
> trying to address that from a geometry / rendering complexity point of
> view, but also, I'd love to see my laptop being able to get the best out
> of its hardware.
> Perhaps we need to account for periods when the CPU has tasks idle
> waiting for GPU operations which would be sped up by increasing some
> chip power state.
> I'm probably not up to coding this all, but if the idea sounds feasible,
> I'd love to know, so I might be able to have a tinker with it.
Instead of just watching frequency, maybe use powertop to watch CPU
C-states as well? I'd suspect those to have more impact on graphics
than CPU frequency, though the two should be related in terms of when
C-state drops don't appear to matter for performance here on Ironlake
with my test app, but things may be different for your hw. If C-state
reductions matter, I think there's supposed to be a way for the kernel
waits to declare how long they expect to wait (1/refresh, I'd say) so as
to not drop C-state if it won't pay off. We should be declaring that if
we can anyway, and it might help your workload.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the Intel-gfx