Overclocking with retropie
-
@RetroResolution said in Overclocking with retropie:
@dankcushions interesting point regarding reicast, thanks.
In general I found that overclocking on the Pi 3 really only helps lr-pcsx_rearmed with enhanced resolution under some circumstances (Gran Turismo 2 really pushes the hardware), but is generally useful for n64 emulation. It also really helps when recording audio/video from retroarch.
I use my Pi 3 also as a lightweight Linux PC with the Raspbian lxde desktop, where overclocking really helps, especially web browsing (chromium), compiling code, ffmpeg transcoding, any graphics work.
That said, I agree that the Pi 3 at a stock 1200mhz is plenty fast ernough for the majority of RetroPie emulators.
What about PPSSPP? Does anyone have insight as to the bottleneck for that emulator? That is, CPU vs GPU...
-
@Rion some impressive heatsinks there - water cooling a Pi, now that is an extreme approach!
[Edit] Really interesting videos - 30 degrees Celsius temp drop with the large passive custom copper heatsink is amazing - all four cores at 100% at a sustained 50 degrees Celsius - no thermal throttling. I'd love that!
I wish someone would make a kit comprising a custom case, a large copper heatsink, and a little thermal compound...
-
@dankcushions
Would this explain why I'm getting hang ups and freezes on code veronica? I did read cv is very graphics intensive -
@vinylash said in Overclocking with retropie:
@dankcushions
Would this explain why I'm getting hang ups and freezes on code veronica? I did read cv is very graphics intensivei don't think there's a single dreamcast game that runs without some sort of severe issue on the pi 3. GPU just isn't up to it.
-
@dankcushions I'm still soak-testing after removing the GPU overclock; was interested to read just now that the core_freq entry which sets GPU frequency also controls the L2 cache speed, which would explain why the GPU setting could theoretically trigger freezing even in a command-line bench test.
[Edit - seems this information applies only to the Pi 1 - details, below]
If a post has helped you, please encourage the author by up-voting via the ^ icon located in the bottom-right corner.
RetroResolution.com - Adventures in retro gaming on original hardware and via emulation with RetroPie on the Raspberry Pi.
-
Thanks for the info guys. Some really helpful stuff. I've also seen that you can oveclock the sd card slot to 100mhz. Would this improve performance on retropie? My card I'm using is a SanDisk extreme 32gb.
-
@dankcushions although I haven't used any of my 3 (!) Dreamcasts in a long while, it seems to me that Reicast is rendering at a higher resolution than the real hardware.
I tried using the runcommand menu to change the render resolution, without any joy. I thought I could reduce the processing burden in the same manner as I do with the non-retroarch mupen64plus...
If a post has helped you, please encourage the author by up-voting via the ^ icon located in the bottom-right corner.
RetroResolution.com - Adventures in retro gaming on original hardware and via emulation with RetroPie on the Raspberry Pi.
-
@RetroResolution said in Overclocking with retropie:
@dankcushions I'm still soak-testing after removing the GPU overclock; was interested to read just now that the core_freq entry which sets GPU frequency also controls the L2 cache speed, which would explain why the GPU setting could theoretically trigger freezing even in a command-line bench test.
i thought it was gpu_freq that sets GPU frequency. are you thinking of the pi2? even so, v3d_freq is the pertinent one for me. gpu_freq raises the gpu core for all various GPU tasks (h264 encoding etc) - seems irrelevant for emulation!
that said, corefreq may help with ram transfers i guess.
-
@vinylash most emulators run entirely in-process, loading everything in to ram. I recall reading that the PSP emulator uses SD card access, but I don't use it so can't be sure.
As a rule I personally leave the SD card frequency alone for fear of card corruption (as per the bad old days of early model 1 PiS and firmware) -
@RetroResolution
This is interesting. It would explain why reicast is so power hungry. My primary objective is to get reicast running better. Although as you say the gpu may not be up to the job. -
@RetroResolution said in Overclocking with retropie:
@dankcushions although I haven't used any of my 3 (!) Dreamcasts in a long while, it seems to me that Reicast is rendering at a higher resolution than the real hardware.
I tried using the run command menu to change the render resolution, without any joy. I thought I could reduce the processing burden in the same manner as I do with the non-retroarch mupen64plus...
you need to change the display mode. framebuffer is only for retroarch i think?
anyway, i think latest versions of retropie run reicast in 640x480 (native dc res) regardless, thanks to SDL scaling.
-
@dankcushion just going by what I've read elsewhere; not entirely sure as I've seen contradictory information in various places regarding the various config,text settings
The guide I read earlier is from back in 2013, and states
"Core_freq – GPU core frequency, has an impact on ARM performance since it drives L2 cache"
http://forum.hwbot.org/showthread.php?t=81294&page=2
Overclocking the GPU / 3d components is an area I've not investigated thoroughly - my guides concentrate on the CPU mainly, and upon testing ram, CPU, and SD card stability.
[Edit - seems this information applies only to the Pi 1 - details, below]
-
@dankcushions thanks, I thought that was a retroarch setting, but wasn't really trying hard once I realised how much reicast struggles on the Pi 3. The scaling is doing an impressive job, as it looks far crisper than 480 vertical lines has any right to!
-
Re: core_freq
http://elinux.org/RPiconfig states:"core_freq- Frequency of GPU processor core in MHz. For models prior to the Pi2, this has an impact on ARM performance since it drives the L2 cache. The ARM on the Pi2 has a separate L2 cache. Default 250"
Seems that this doesn't affect the L2 cache on the Pi 2 or Pi 3.
The gpu_freq entry appears to set multiple parameters simultaneously:
"gpu_freq Sets core_freq, h264_freq, isp_freq, v3d_freq together. Default 250"
Looks like this page hasn't been updated since the Pi 2 was released.
-
Whilst I'm glad to further my knowledge re: overclocking, it does leave me unable to explain why removing the GPU overclock appears to have stabilised the system during two very long (10 hours, 12 hours+) soak tests
I've been running mprime on two cores (restricting the temperature to a maximum of around 75 degrees Celsius, to avoid thermal throttling overriding the CPU overclock) -
@RetroResolution soak-test update: the pi froze after 12.5 hours - seems the core_freq isn't the cause. Shows that stability testing is an arduous process too...
-
@dankcushions
When you say the latest version runs reicast in 640x480, how New is that? I'm wondering if I update retropie to latest, it might run smoother on my pi 3?
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.