2016-02-03, 13:02
(2016-02-03, 12:25)menakite Wrote:(2016-02-03, 02:39)Milhouse Wrote: I'd suggest gpu_freq=400 which will help decode images more quickly (those that are decoded by the GPU, anyway).Interesting - does this result in a measurable improvement (will test myself tonight)?
It seemed to, it's not a night and day difference but Kodi did appear able to keep up for longer while rapidly displaying posters and fanart (I have a stress test built in to texturecache.py). With just the GPU, Kodi would stop displaying posters/fanart sooner (longer - slower - scroll interval) as Kodi couldn't decode artwork fast enough. With GPU+ARM, Kodi would continue to display the same artwork while using a shorter (more rapid) scroll interval.
When stressing the GUI (scrolling rapidly through the Confluence "Thumbnails" movie view, 1080 fanartres/720 imageres), a GPU+ARM at stock frequencies would produce a similar GUI performance to an overclocked GPU that had no additional ARM decode support.
It may be the case that the GPU is still slightly better at decoding "big" artwork (eg. 1080 fanart) than the ARM cores, but currently there is no prioritisation over which resources decode which types of artwork. but it's still better than the GPU doing all of the decoding.
(2016-02-03, 12:25)menakite Wrote: Also, is there a more specific overclock setting? I ask because after reboot I noticed that h264 is always 250 MHz even when not in use. I'm wondering if there's a way to keep previous behavior (0 when not in use, 250 when in use, 300 - or 400 in this case - when needed).
That's how it should behave (unless you've got force_turbo=1 when it will be either 0 or 300/400), but sometimes the h264 will remain enabled even when not in use (when it should be off, zero). I get this even on a headless Raspbian system with gpu_mem=16 and there's no way I'm using the h264 block on that system - as I type this, Raspbian is showing 300MHz (force_turbo=1) for the h264 block...!