Overclocking the Pi3b+ GPU (Results)

quicksilver

@hhromic Ah thank you for the clarification! I completely missed the "AND".

hhromic

Interesting discussions and investigations guys!
I still advocate to leave ondemand as the system default and educate users on how overclocking works and how to use the governor runcommand option, as it's the soundest/safest approach. This topic should definitively be used to update/populate the Wiki entry on the topic.

The only improvement I would consider in this subject would be to implement a per-command governor setting in runcommand, similar to how video modes are set currently. For example create a governors.cfg file alongside videomodes.cfg.

This would give the flexibility for the governor to be configured per-emulator as necessary, e.g. performance for lr-mupen64plus and default for lr-gambatte, or any other customisation.

What do you think @buzz? should be a fairly easy thing to code taking the videomode functionality as template.

BuZz

@hhromic The interface is busy enough as it is. I don't think this warrants that level of configuration. So no thanks.

hhromic

@BuZz umm I could have sworn there was already a menu entry for the cpu governor in runcommand, but you are right, it is only read from the global options and configured externally in the runcommand scriptmodule. I agree that adding this to the menu would add two more entries to the already crowded interface.

The idea was more for these advanced tinker users (like in this topic!), so if you reconsider it in the future, perhaps we can add the functionality without exposing any menu items, i.e. requiring editing the governors config file manually.

BuZz

@hhromic advanced users can do this via an onstart/onend script if they want.

hhromic

@BuZz you mean adding something like this (and the corresponding reverting snippet in onend):

#!/usr/bin/env bash

system="$1"
emulator="$2"

if [[ "$emulator" == "lr-mupen64plus" ]]; then
      for cpu in /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_governor; do
        echo performance | sudo tee "$cpu" >/dev/null
    done
fi

Instead of adding something like this to a governors.cfg file?

lr-mupen64plus = performance

:)

BuZz

Yes. If you're going to ignore the work involved putting it into runcommand and future maintenance of the code also.

But putting your sarcasm to one side - You can simplify that script on the RPI by just using cpu0 and skipping the loop.

no need for a corresponding reverting snippet either - can just be one line to restore to ondemand.

hhromic

@BuZz sorry I didn't mean to be rude, I'm genuinely being friendly here. I realise being sarcastic wasn't a good move. Apologies.

Of course I'm not ignoring the work needed to code this functionality, and I was going to volunteer on doing it and testing it myself if you felt it was a contributing addition to the system. I understand your safety/maintainability concerns very well and respect your wishes as the project leader. If you don't think is worth it, no hard feelings and all good :thumbsup.

no need for a corresponding reverting snippet either - can just be one line to restore to ondemand.

I was just refering to the actual nice approach in runcommand where it saves the current governor and restores it on exit :)

Actually runcommand has all the functionality built-in to set/unset the governor already and is robust, that's why I liked the idea of implementing it in there instead of onstart/onend scripts.

BuZz

@hhromic no worries. the functionality in runcommand is technically overkill on the RPI as the cores are not independently controllable (hence why using cpu0 is enough).

Parabolaralus

@Brunnis Thank you for taking the time to research and post this data!

Rion

@Brunnis I have also noticed the slowdowns happening in certain games using ondemand CPU governor.

I never bothered with Overclocking but just changed to performance instead.

But if would be interesting to see if there is anyway to optimize cpu governor ondemand.

Brunnis

@dankcushions

no, i'm just articulating what i mean when i say that the data presented is not the "smoking gun", but your personal observations of a stutter is.

Fair enough.

i think the sampling_down_factor might be the one we would tweak:

sampling_down_factor:

This parameter controls the rate at which the kernel makes a decision

on when to decrease the frequency while running at top speed. When set

to 1 (the default) decisions to reevaluate load are made at the same

interval regardless of current clock speed. But when set to greater

than 1 (e.g. 100) it acts as a multiplier for the scheduling interval

for reevaluating load when the CPU is at its top speed due to high

load. This improves performance by reducing the overhead of load

evaluation and helping the CPU stay at its top speed when truly busy,

rather than shifting back and forth in speed. This tunable has no

effect on behavior at lower speeds/lower CPU loads.

I don't think that will work either. The problem is, again, that the average load is too low. Whether we stretch out the sample period over 1, 2, 10 frames, the average load will be close to the same and far below the required 95% that's needed to stay at the highest speed.

The way I see it, rapid highly periodic loads like these are hard to handle. The same issue occurs when running RetroArch on Windows 10 machines with modern Core processors, so it's not isolated to the Raspberry Pi. The only possible solutions I've been able to come up with so far are to:

Decrease the sample period, so that reactions to load changes can be carried out faster. If the default sample period is really 10 ms, that means more than half the execution time of a frame can be spent at the lower frequency before the CPU is instructed to increase clocks. The sample period would need to be drastically reduced in order to minimize the time spent down clocked after beginning actual timing critical work.
Use the "performance" governor. This completely eliminates the inefficiency of needing to sample CPU load before reacting.

That's it for me on the topic. I'm fine with using the run command settings to control this, like I always have before. Sometimes it's just fun to try to understand the mechanics behind a behavior. :-)

@Rion said in Overclocking the Pi3b+ GPU (Results):

I have also noticed the slowdowns happening in certain games using ondemand CPU governor.

Even without using video_max_swapchain_images=2?

@Rion said in Overclocking the Pi3b+ GPU (Results):

I never bothered with Overclocking but just changed to performance instead.

Yeah, that's the correct approach. Starting out with overclocking would be bad, since you're then just working against a mechanism that's now even more prone to try to lower the frequency. So, first change the governor, then overclock if performance still isn't good enough. :-)

@Rion said in Overclocking the Pi3b+ GPU (Results):

But if would be interesting to see if there is anyway to optimize cpu governor ondemand.

I think the nature of the load makes it hard. It will never be as performant as simply using the "performance" governor. Well, if you tweak the "ondemand" governor so that it considers the emulator load to be high enough to not down clock inbetween frames, then it will perform the same as the "performance" governor. But then there's no point in doing the optimization in the first place, since it won't save you any power consumption over the "performance" governor anyway!

Riverstorm

Performance is one the first things I turn on with a new build for the past few years. There's several MAME titles that you can feel the difference between on-demand vs performance when gaming. I don't know if it's coincidental but the more demanding titles seem to really show which almost seems contradictory but maybe another component is bottlenecking it.

If you open SSH and use watch you can see it constantly yo-yo while playing almost any game. It never stays at maximum performance like when using the performance setting.

It takes a minute to turn it on, done! :)

pi2user

Another tool you can use to check up on cpu performance is nmon (nigel's monitor). It is a standard debian package that was originally developed for monitoring enterprise level POWER systems.
It shows performance on a per-core basis, so you can see how much any individual core is being used. It is interesting to see how load is spread out over all the cores even in a single-core task like retroarch. The system appears to frequently reassign load to different cores, so each core gets a turn at running fully loaded.
Install and run nmon, then press c for cpu display per-core, and then t for top procs. There's also l for long-term cpu stats but this is overall and not per-core. q quits out of nmon.

dankcushions

@Brunnis said in Overclocking the Pi3b+ GPU (Results):

@dankcushions

i think the sampling_down_factor might be the one we would tweak:

sampling_down_factor:

This parameter controls the rate at which the kernel makes a decision

on when to decrease the frequency while running at top speed. When set

to 1 (the default) decisions to reevaluate load are made at the same

interval regardless of current clock speed. But when set to greater

than 1 (e.g. 100) it acts as a multiplier for the scheduling interval

for reevaluating load when the CPU is at its top speed due to high

load. This improves performance by reducing the overhead of load

evaluation and helping the CPU stay at its top speed when truly busy,

rather than shifting back and forth in speed. This tunable has no

effect on behavior at lower speeds/lower CPU loads.

I don't think that will work either. The problem is, again, that the average load is too low. Whether we stretch out the sample period over 1, 2, 10 frames, the average load will be close to the same and far below the required 95% that's needed to stay at the highest speed.

agree i think you’d also have to raise that threshold also (which is possible)

Well, if you tweak the "ondemand" governor so that it considers the emulator load to be high enough to not down clock inbetween frames, then it will perform the same as the "performance" governor. But then there's no point in doing the optimization in the first place, since it won't save you any power consumption over the "performance" governor anyway!

for those situations, absolutely, but the issue is that using the performance governer puts ALL applications launched via run command at full speed, which includes multithreaded or otherwise low-load applications (kodi, pixel desktop (??), maybe even some emulators like gambette, etc). i still like the idea of finding a way to make the ondemand governer work for us.

Brunnis

@dankcushions said in Overclocking the Pi3b+ GPU (Results):

@Brunnis said in Overclocking the Pi3b+ GPU (Results):

@dankcushions

i think the sampling_down_factor might be the one we would tweak:

sampling_down_factor:

This parameter controls the rate at which the kernel makes a decision

on when to decrease the frequency while running at top speed. When set

to 1 (the default) decisions to reevaluate load are made at the same

interval regardless of current clock speed. But when set to greater

than 1 (e.g. 100) it acts as a multiplier for the scheduling interval

for reevaluating load when the CPU is at its top speed due to high

load. This improves performance by reducing the overhead of load

evaluation and helping the CPU stay at its top speed when truly busy,

rather than shifting back and forth in speed. This tunable has no

effect on behavior at lower speeds/lower CPU loads.

I don't think that will work either. The problem is, again, that the average load is too low. Whether we stretch out the sample period over 1, 2, 10 frames, the average load will be close to the same and far below the required 95% that's needed to stay at the highest speed.

agree i think you’d also have to raise that threshold also (which is possible)

Well, if you tweak the "ondemand" governor so that it considers the emulator load to be high enough to not down clock inbetween frames, then it will perform the same as the "performance" governor. But then there's no point in doing the optimization in the first place, since it won't save you any power consumption over the "performance" governor anyway!

for those situations, absolutely, but the issue is that using the performance governer puts ALL applications launched via run command at full speed, which includes multithreaded or otherwise low-load applications (kodi, pixel desktop (??), maybe even some emulators like gambette, etc). i still like the idea of finding a way to make the ondemand governer work for us.

I was still stuck in thinking emulation (for which I’m not convinced ondemand is a great idea). I agree for Kodi and the likes.

As for trying out an optimization: I’d start out by either testing half as long sampling_rate OR decreasing the up_threshold to something like 50%. It won’t fix all possible performance issues, but there’s a good chance it’s much better than the defaults for the RetroPie use case.

Rascas

Here is the default settings of Libreelec:
https://github.com/LibreELEC/LibreELEC.tv/blob/libreelec-9.0/projects/RPi/initramfs/platform_init
I believe they are the same now on Raspbian/RetroPie. The only difference is the io_is_busy, which improves performance when in heavy reading/writing to the sdcard, for example streaming a torrent. But probably not so usefull for emulation.

hhromic

@Rascas said in Overclocking the Pi3b+ GPU (Results):

I believe they are the same now on Raspbian/RetroPie.

Can confirm from one of my Raspbian devices:

/sys/devices/system/cpu/cpufreq/ondemand/io_is_busy: 0
/sys/devices/system/cpu/cpufreq/ondemand/up_threshold: 50
/sys/devices/system/cpu/cpufreq/ondemand/sampling_rate: 100000
/sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor: 50

Silent

I really like the snippet with setting individual emulators to performance governor! I'd love to have that set eg. for PSX but I wouldn't necessarily want it for GBC or Kodi. Onstart sounds like a good way to optimally utilize the option!

quicksilver

So after a lot of testing it looks like the two pi3b+'s are stable at 590mhz core_freq and 615mhz respectively. Compared to my 3b which was stable up to 565mhz core_freq this is a pretty good jump. My old pi2's were only stable up to 525 and 535mhz core_freq. And they are all supposed to have the same GPU which means there must be some improvements with the manufacturing process from each generation of pi or perhaps power regulation is better too. I know that my testing sample is fairly small but there is a clear trend in the 6-7 different pis I have tested that shows that even though the GPU is the same in all models, later models definitely seem to have more GPU overclocking headroom. While this may not mean much to most people, it makes a noticeable difference when trying to run N64 or Dreamcast games that are right on the edge of being playable, in some cases an overclock is just enough to push it into the playable zone.

I should also note that while its often discussed that the CPU is not the bottleneck for N64 emulation on the pi, this is only true of the pi3b and 3b+. Going back and testing my pi2's there were quite a few N64 games that were pushing its cpu past 100% usage, even when overclocked to 1075mhz.