[Milhouse]

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.

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...!

[ZwartePiet]

My iozone results for Samsung EVO 16GB SD card, RPi2, OpenELEC (arm=1000, core=500, gpu=400, sdram=500, force_turbo=0):

sdhost@50MHz,

Code:

.                                                              random   random
              kB  reclen    write  rewrite     read   reread     read    write
           51200       4     1519     1501     5426     5378     4644      920
           51200     512     7806     8038    21797    22306    22170     7799
           51200   16384    10315     9902    22566    22553    22543     9634

sdhost@100MHz:

Code:

.                                                              random   random
              kB  reclen    write  rewrite     read   reread     read    write
           51200       4     1853     1796     6406     6405     5796      999
           51200     512     9562     9300    42585    42647    42354     8124
           51200   16384    10270     9221    42633    42635    42629     8730

100Mhz relative to 50MHz:

Code:

.                                                              random   random
              kB  reclen    write  rewrite     read   reread     read    write
           51200       4   +22.0%   +19.7%   +18.1%   +19.1%   +24.8%    +8.6%
           51200     512   +22.5%   +15.7%   +95.4%   +91.2%   +91.0%    +4.2%
           51200   16384    -0.4%    -6.9%   +88.9%   +89.0%   +89.1%    -9.4%

I see similar percentage gains, but the NOOBS card is quite a bit faster with 4K small block files (62% higher random read speeds). I'm not using force_turbo, but I don't think that makes a difference here.

[ZwartePiet]

My config.txt file has been edited for gpu_mem_1024=320. I assume it's working, but I don't know how to verify.

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.

Overclocking the GPU increased the animation speed in the "Cover Flow" style views I described earlier. If 60fps was perfect motion, I'd estimate the original performance ~30fps and the overclocked GPU performance ~45fps. I don't have a large enough library to check scrolling performance. Without numbers or benchmarking this all could be placebo for me.

I'm on 15.2 right now and look forward to 16.0, not to mention 17.0! I'd help debug in the beta thread, but both of my Pi's are in daily use by other people -- stability is priority #1. Honestly, I'm amazed you guys are still squeezing performance and features out of the little guy.

Thanks for the help. My Pi just got a little bit better.

[Milhouse]

My config.txt file has been edited for gpu_mem_1024=320. I assume it's working, but I don't know how to verify.

Kodi will confirm your GPU memory in kodi.log:

Code:

21:27:06  14.030357 T:1963815824  NOTICE: ARM mem: 688MB GPU mem: 320MB MPG2:1 WVC1:1

[menakite]

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.

You know what... it seems to have made an actual difference for me.
I had to switch from Amber to a Krypton skin after recent changes, picked Aeon Nox (mikesilvo164's mod). It's perfectly smooth, except when entering movies where I was seeing a ~2 seconds lag (possibly view specific). After overclocking the GPU this delay is now reduced to something less than a second - acceptable, as this only happens when entering movies.

Still a bit odd that h264 (and v3d, ...) are always awake even when not in use, but it's not really an issue. Just a bit strange.

</offtopic>

[popcornmix]

Still a bit odd that h264 (and v3d, ...) are always awake even when not in use, but it's not really an issue. Just a bit strange.

The blocks are powered off when not in use. Just the clock is left running. That takes negligible power so it's really just a cosmetic thing.