[Proposal] Global cpufreq script

[cobaltgit]

Instead of having a cpufreq script per emulator, I propose the use of a global cpufreq script stored in /System/usr/trimui/scripts/cpufreq.sh to better improve consistency and clean up emulator folders.

This new script will come with three different CPU modes:

• Smart (a modified conservative governor that checks CPU load 2.5 times per second and scales up or down in response) (credit to rymsar from the spruce team)
• Performance (constant 1.8GHz)
• Overclock (constant 2GHz)

Below is my proposed script:

#!/bin/sh

for i in 0 1 2 3; do # enable all cpu cores
    echo 1 > /sys/devices/system/cpu/cpu$i/online
done

case $1 in
    "smart"|*) # default
        echo conservative > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
        echo 30 > /sys/devices/system/cpu/cpufreq/conservative/down_threshold # 30% cpu load
        echo 70 > /sys/devices/system/cpu/cpufreq/conservative/up_threshold # 70% cpu load
        echo 3 > /sys/devices/system/cpu/cpufreq/conservative/freq_step
        echo 1 > /sys/devices/system/cpu/cpufreq/conservative/sampling_down_factor
        echo 400000 > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate
        echo 200000 > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate_min
        echo 408000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
        echo 1800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
        ;;
    "performance")
        echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
        echo 1800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
        ;;
    "overclock")
        echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
        echo 2000000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
        ;;
esac

To call this script from an emulator launch script, just do

/mnt/SDCARD/System/usr/trimui/scripts/cpufreq.sh "smart"

I think the smart CPU mode will be especially beneficial to battery life on systems PSX and below, but it may need to be modified due to differing CPU steppings than what this mode was developed on.

[rkr87]

This is a good idea, however, I'm working on an app that allows customising cpu profiles per emu via a gui, while I could have it parse the full launch.sh and only edit relevant parts it would add unnecessary complication (moreso when an emu has more than one launch script).

If possible I would prefer that launch.sh still calls an emu specific cpufreq.sh as it currently does, and instead, the cpufreq.sh calls the global cpufreq.sh script.

EG: /mnt/SDCARD/Emus/CPS1/launch.sh

EMU_DIR=/mnt/SDCARD/Emus/CPS1
$EMU_DIR/cpufreq.sh

/mnt/SDCARD/Emus/CPS1/cpufreq.sh

/mnt/SDCARD/System/usr/trimui/scripts/cpufreq.sh "smart"

I'll then include the various options available in the global script to be configurable by user in my app along with the ability to provide overrides for some items;

[cobaltgit]

Sorry I've only just seen this, I like your way of thinking but my original idea was to reduce the overall "bloat" of crossmix by having a single centralised script

[cobaltgit]

Also changing the active cpu cores seems to have a placebo effect on power efficiency for the most part

[rkr87]

Seems shortsighted, removing the already separated concerns for the sole benefit of deleting a single file per emu, a file that doesn't add any complexity or overhead.

I mean it doesn't make a huge difference from my perspective, I can just add the cpufreq.sh files back if they don't exist and reinclude them in any launch scripts specified in the config file... But seems like a pointless exercise.

[cobaltgit]

I see what you're saying, I (or Ry for that matter) originally thought of the smart mode as a "one size fits all" approach for most systems, whereas performance and overclock here are for the systems that need every ounce of CPU power we can get out of this device (namely Dreamcast and Saturn, as N64 and PSP are GPU bottlenecked for the most part)

[rkr87]

And I'm not saying that's a bad idea, the opposite in fact, it's a great idea! But there will always be exceptions (specific games or different cores etc) where the one size approach doesn't work.

It should be as easy as possible for users to tweak those settings if they want to, but not so critical that they have to. I think the combination approach fits that model.

[Nevrdid]

Well, I used same approach as cobal for #187 but really don't think the solution with per system cpufreq.sh is better in any way as you may need different settings per launcher. Imo, you better add a per launcher setting in your app which will just change parameters using sed : e.g : sed -i -E "s/^cpufreq.sh.*$/cpufreq.sh $your_custom_arguments/" "$EMU_DIR/$thelauncher"

[rkr87]

Working with a separate file is far simpler in every aspect, whether that's a separate file per system or per launcher is by the by. Could I have the app read the entire contents of a launch.sh file and conditionally edit specific lines dependant on which settings the user is adjusting, absolutely. But why would I when I can just generate a new file without worrying about any other contents and call it.

If the central script is expanded to offer the same level of customisation as I plan to, then I'd be fine with just passing parameters to that - what I don't want to do is start adding tonnes of extra lines to each launch script to cover the gaps of the central script.

I think that if the central script had the ability to pass a profile that applies additional tweaks (as in Cobalt's "smart" profile) but also accepted additional args to override certain values as in Nevr's it would work well.

Eg cpufreq.sh "smart" -maxfreq 2000000

To have all the benefits of the smart profile with a higher max freq.

EDIT: for clarity I'm only planning to allow users to set a profile and override the governor, min freq & max freq (and maybe # active cores).