2014-12-11, 23:54
core_freq is the important one. That makes xbmc go faster. gpu_freq doesn't make xbmc measurably faster.
core_freq makes the ARM's L2 cache go faster, makes peripheral and sdram access a bit quicker and speeds up some GPU tasks like jpeg decode. All useful.
gpu_freq makes the 3D and video decode blocks go faster - but they are not a bottleneck. You can underclock the video decode block at 150MHz and still play 1080p video. The 3D block is mostly idle when rendering xbmc's gui.
The simple rule is to set gpu_freq to half of core_freq when core_freq >= 500.
if you want to know what happens, then:
core_freq=600 means pll_freq = 2400.
If you don't specify gpu_freq it will not exceed the default of 250 and it will choose the smallest N where pll_freq/(2*N).
This works out at N=5 and gpu_freq=240 which will be fine, although underclocked a fraction (you won't notice).
The next notch up will ne N=4, which gives gpu_freq=300. I'd be surprised if you can measure the difference between that and 240 though.
core_freq makes the ARM's L2 cache go faster, makes peripheral and sdram access a bit quicker and speeds up some GPU tasks like jpeg decode. All useful.
gpu_freq makes the 3D and video decode blocks go faster - but they are not a bottleneck. You can underclock the video decode block at 150MHz and still play 1080p video. The 3D block is mostly idle when rendering xbmc's gui.
The simple rule is to set gpu_freq to half of core_freq when core_freq >= 500.
if you want to know what happens, then:
core_freq=600 means pll_freq = 2400.
If you don't specify gpu_freq it will not exceed the default of 250 and it will choose the smallest N where pll_freq/(2*N).
This works out at N=5 and gpu_freq=240 which will be fine, although underclocked a fraction (you won't notice).
The next notch up will ne N=4, which gives gpu_freq=300. I'd be surprised if you can measure the difference between that and 240 though.
