Overclocking with retropie

dankcushions

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

RetroResolution

@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)

vinylash

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

dankcushions

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

RetroResolution

@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]

RetroResolution

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

RetroResolution

@dankcushions

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.

RetroResolution

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

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

vinylash

@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?