On Sat, 23 Oct 2010 13:02:35 +0100, Peter Clifton <[email protected]> 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 > performance. > > Strangely: > pc...@pcjc2lap:/sys/devices/system/cpu/cpu1/cpufreq$ cat > scaling_available_frequencies > 2401000 2400000 1600000 800000 > > and I only get: > sudo cat cpuinfo_cur_freq > 2400000 > > (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 > throughput. > > 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 they're changed. 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.
pgpZMWcYrje38.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
