Overclocking the Pi3b+ GPU (Results)

[quicksilver]

Just today I received 2 pi3b+'s. One to upgrade my pi3b and one to make a Retropie build for a family member. The Pi3b+ CPU from the factory is 1400mhz. My old pi3b is 1200mhz from the factory and with overclock it was stable at 1325mhz. So the RPI foundation through some wizardry has been able to get the pi3b+ to run stock faster than my pi3b overclocked. This got me wondering if whatever they had done to improve the CPU might also be benefiting the GPU.

The GPU core_freq by default is 400mhz. On my pi3b I was able to overclock and be stable at 565mhz. Anything past that would eventually lead to a hard freeze. However during my initial testing it appears that the two pi3b+'s that I just recieved can handle much more than my previous pi's. The first one I was able to get the core_freq up to 640mhz and was able to play through the first level of goldeneye with no crashing. The second pi3b+ was able to make it up to 625mhz without crashing and I was able to play through the first level of goldeneye as well. I am by no means claiming that they are stable at this speed but it does prove to me that the pi3b+ has much more GPU overclocking headroom than previous pi models. This is very interesting since the pi GPU technically hasnt been changed since the original raspberry pi.

This is good news to all of us who try to get the most out of N64 on the pi. I will be running additional tests for stability over the next few days and will report back my additional findings.

[Brunnis]

Hey quicksilver! I've continued testing my 3 B+ as well (you responded to me on Reddit a couple of weeks ago). I have continued to run Quake 3 as a test and I've tried many different frequency combinations. The tests I've been running are:

Test 1
Quake 3 (this loads up one CPU thread, plus the GPU of course)
memtester (one instance, 512M)
sysbench (prime test, 2 threads)

Test 2
Linpack

Test 3
memtester (four instances, 4*175M)

The test that makes my Pi fail earliest is Linpack. Neon code seems to be a weak spot of this SoC. 1475 MHz is stable looping Linpack for ~3 hours at over_voltage=1. 1500 MHz won't return correct results even with over_voltage=4.

Here are my tested stable settings so far:

arm_freq=1475
core_freq=600
v3d_freq=400
sdram_freq=550
over_voltage=1
temp_soft_limit=70

arm_freq and sdram_freq are pretty much maxed out. sdram_freq=600 was not stable even with a small voltage increase, so no reason to push further. I have not tested to find the max on core_freq and v3d_freq. core_freq seems pretty pointless to push past 600 MHz. The limit will be close and it has a small effect on performance for what I need it for. A v3d_freq of 400 MHz is already a 33% increase over stock and I'm quite happy with that.

I should mention (but you probably already know) that core_freq has a pretty limited effect on performance in a game like Quake 3 (possibly more important for N64 emulation?). v3d_freq, however, has a massive effect! A few timedemos I ran:

[arm_freq/core_freq/sdram_freq/v3d_freq]
1400/400/450/300 (default): 76.2 FPS
1500/600/600/300: 85.5 FPS (+12.2 %)
1500/600/550/400: 105.5 FPS (+38.5 %)

Another interesting thing is that I only had to use over_voltage=1 to max out the CPU. Any higher frequencies were not stable, even with a lot higher voltage. core_freq and v3d_freq can obviously be pushed high without a lot of extra voltage as well, as my testing shows. So, I think many people are far to generous with the voltage. People seem to almost mechanically just set the over_voltage to 6 (or even 8) without even testing if it's actually needed.

[Rascas]

@Brunnis Yes, the v3d_freq is the most important part for anything that uses OpenGLES, like N64 emulators and Quake3. Besides the cpu_freq of course.
About the over_voltage, I believe the maximum for the RPi 3/3+ is 4. Any value above, has the same voltage of 4. There is a nice utility made by Milhouse, that you can use to monitor pretty much everything from the Pi:
https://github.com/MilhouseVH/bcmstat

[quicksilver]

@Brunnis hey good to hear from you again! And thanks for the update on your testing. It's interesting to see how overclocking v3d frequency got you such huge performance gains in quake 3. Interestingly enough v3d frequency doesn't seem to be the main bottleneck for N64 emulation but is instead the GPU core_freq. Though recently I have discovered that overclocking v3d does give a noticable improvement to a few games while I'm running the libretro version of mupen64plus. I'll have to do additional testing on this as well.

[quicksilver]

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

sdram_freq=600 was not stable even with a small voltage increase, so no reason to push further

I have read some posts by some of the RPI engineers on the official RPI forums that based on your sdram overclock the sdram_over_voltage will scale somewhat automatically. For example if you set 550mhz then it scales your sdram over volt to 2. I'll have to see if I can find the post.

[Parabolaralus]

Id like to add to this that ive been playing with my 3b+'s for quite a while now and one of them doesnt handle overclocking all that well. Anything past 570 for core, gpu or v3d causes it to stall out eventually as well as 1450 is the max for cpu. Dont even bother touching the RAM on that board...

My other one which i bought at release handles quite a bit and will run for 3 days (probably more if it let it) under moderate load with the following config:
arm_freq=1500
core_freq=580
v3d_freq=580
over_voltage=6
sdram_freq=733
force_turbo=1

Ive since scrapped that config for the following and reicast as well as some n64 games run beautifully:
arm_freq=1200 I know i went down on this - i dont need it.
core_freq=610 This is where the magic happens, but even a 615 will cause a emergency boot occasionally failing to mount /boot. It will run for days even at 630 ~IF~ i can get it to boot lol
force_turbo=1

edit: fail on the cpu/arm freq...

[quicksilver]

@Parabolaralus

Keep in mind that any overclock that causes your system to freeze or exhibit abnormal behavior, whether its immediately or days later is unstable. There also isnt much point underclocking your system or using force_turbo. The CPU governor controls when to apply your overclock settings. Force_turbo just applies your overclock even when your pi is idle (which is pretty pointless).

[Parabolaralus]

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

@Parabolaralus

Keep in mind that any overclock that causes your system to freeze or exhibit abnormal behavior, whether its immediately or days later is unstable. There also isnt much point underclocking your system or using force_turbo. The CPU governor controls when to apply your overclock settings. Force_turbo just applies your overclock even when your pi is idle (which is pretty pointless).

Yep, and thats why 610 is where i leave the core_freq. I actually noticed some small slowdowns in the middle of certain games (super mario worlds intro for example) which i was able to correct by using force_turbo.

Unless im testing an overclock which i wont be doing anymore the pi is being used so force_turbo being on isnt hurting anything in my case.

[quicksilver]

@Parabolaralus something you could try is to set the CPU governor to performance mode. Can be found in the runcommand options in the retropie setup

[Brunnis]

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

@Parabolaralus something you could try is to set the CPU governor to performance mode. Can be found in the runcommand options in the retropie setup

Yep, that should be the preferred way of forcing the CPU to max clocks, since it will prevent it from running all out when you're in the menu. Does anyone know why this is not the default in RetroPie? The on demand governor causes issues with some SNES games as well, at least if you use other settings that are demanding.

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

sdram_freq=733

Not saying it's impossible, but I very much doubt that this amount of overclock is stable. How have you tested it?

[Brunnis]

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

I have read some posts by some of the RPI engineers on the official RPI forums that based on your sdram overclock the sdram_over_voltage will scale somewhat automatically. For example if you set 550mhz then it scales your sdram over volt to 2. I'll have to see if I can find the post.

I looked around, but couldn't find any info. So, I used vcgencmd to measure the voltages under load at stock frequencies and with overclock:

Command used: for id in core sdram_c sdram_i sdram_p ; do echo -e "$id:\t$(vcgencmd measure_volts $id)" ; done

Stock:

core: volt=1.3688V
sdram_c: volt=1.2500V
sdram_i: volt=1.2500V
sdram_p: volt=1.2250V

Overclocked:

core: volt=1.3938V
sdram_c: volt=1.2500V
sdram_i: volt=1.2500V
sdram_p: volt=1.2250V

Fortunately, there is no automatic SDRAM voltage hike. Only the CPU has received the specified +0.025V due to over_voltage=1.

EDIT: It's interesting to note that the official documentation says default SDRAM voltage is 1.2V. Either they upped it for the Pi 3 B+ (since it originally had 500 MHz SDRAM instead of 450 MHz on the Pi 3 - they later lowered this due to stability issues), or default values are tuned differently between specimens.

EDIT 2: Running a 24h test of Quake 3 + sysbench (2 threads) + memtester 512M now. If that's successful, I'll consider this Pi stable at those settings. It's a moderate CPU overclock (5%) but nice SDRAM, core and GPU overclocks (22%, 50% and 33% respectively).

[dankcushions]

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

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

@Parabolaralus something you could try is to set the CPU governor to performance mode. Can be found in the runcommand options in the retropie setup

Yep, that should be the preferred way of forcing the CPU to max clocks, since it will prevent it from running all out when you're in the menu. Does anyone know why this is not the default in RetroPie? The on demand governor causes issues with some SNES games as well, at least if you use other settings that are demanding.

it's a fair point. i assume it's not set in the default image because ondemand is what raspbian defaults to. depending on what your pi is used for, you may still want it to be ondemand - eg, portable builds. however i would have thought that for rpi3 and 2 builds that 'performance' would be a good default. maybe @BuZz has a view?

[pjft]

Wow.

@Parabolaralus and @Brunnis setting core_freq to 600 pretty much makes Crazy Taxi on the Dreamcast run a lot smoother without the audio skipping issues that plagued it in the default settings. Only skipping in minor occasions now, whereas previously after a 20-30 seconds it'd start skipping every couple of seconds when there were a lot of polygons on screen.

Thank you!

[BuZz]

@dankcushions I prefer to stick with OS defaults.

[quicksilver]

@Brunnis here it is:

https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=6201&start=975

Man that took some digging 😂

There is a post on that page by Millhouse about it, and on the next page it looks like Dom (RPI engineer) confirms it. However firmware is constantly changing and sometimes there are changes which aren't well documented so who knows what's going on now.

[mitu]

@BuZz I think @dankcushions meant why isn't performance set for the Runcommand setting by default, so performance would be switched on only just during gameplay, but the default (ondemand) is preferred outside of gameplay.
@dankcushions or am I wrong ?

[dankcushions]

@mitu i didn't but that is a better idea! :)

[hhromic]

@dankcushions @mitu @BuZz while setting the scheduler to performanceby default in runcommand is a tempting idea, I would advocate against it. Setting this could potentially make RPIs to overheat without users being aware of it. At least in my experience, I have never had the need to set the scheduler to performance and things runs nice for me.
I think the best approach here is to educate the users about the CPU scheduler more than forcing a potentially troublesome option without their knowledge.

[BuZz]

@mitu I understood. I don't want to default to switching the governor on launch.

[quicksilver]

Setting to performance is a small change that really shouldnt make a significant difference when it comes to wear and tear on a pi but I agree with buzz that it should be up to the user to make that decision. I think there is some documentation in regards to the CPU governor modes in the retropie docs but maybe we can clarify that performance mode does help a few games/systems run smoother (perhaps it already says this, need to review). I would be happy to make any edits to the wiki if people feel that it is pertinent info.