If you are annoyed by your device switching refresh rate to 60FPS or that you are unable to record a video for more than 2 minutes say no more! According to my findings
Sony maxed out all the frequencies without any throttling during camera usage and applied kill switch at 55C.
As for any other use case scenarios, there is an aggressive throttling and forcing screen back to 60FPS, with an exception of using Xperia Stream or Endurance modes. As you may have guessed that these limitation are not to protect the device, but avoid any law suits from people who burned their hands.
Behold!
I present you thermal config mod that will make your device usable and keep your hands warm.
Of course at your own risk, I do not take any responsibility for broken devices, burned hands, radiation sickness or any other catastrophic events.
Description:
During your normal usage (not gaming or camera) the throttling will remain the same, BUT your screen won't switch back to 60FPS.
If you add your game/app to the game enhancer and select "performance profile" it will throttle way less aggressively. Max temperature is changed from 56C to 61C, screen refresh rate will only drop if the display itself will reach 45C.
In "balanced" profile the temperature limit is set to 58C, frequencies are limited to 1574Mhz (Little)+1651Mhz (Big)+2054Mhz(Prime)+545Mhz(GPU).
"Battery mode preferred" is set to 57C with the following limits: 1267Mhz+1325Mhz+1728Mhz+492Mhz.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Camera related profiles are set to 63C.
Video recording profile is set to endurance mode (66C temp limit) with a little bit of throttling to cool device down
During recording device will show warning, but won't disable camera functionality. However if the camera module itself will reach the limit temperature (untouched by me), the recording will stop. Additionally modem might be temporary switched off to cool device down.
Is this safe?
As safe as using endurance mode.
I took thermal profile for Xperia Stream dock thermal limits from endurance mode, so it is relatively safe for the device, but may not be as safe for you, if you have sensitive skin.
I strongly recommend using stick/stand when recording high quality videos for a longer periods of time.
Instructions:
You need root and magisk.
Install this module
GitHub - HuskyDG/magic_overlayfs: Make system partition become read-write (it is also possible without Magisk)
Make system partition become read-write (it is also possible without Magisk) - GitHub - HuskyDG/magic_overlayfs: Make system partition become read-write (it is also possible without Magisk)
github.com
After rebooting go to oem/etc with any root file manager, enable R/W and replace the thermal-engine.conf and change.cfg for newer versions.
Make sure to set the same permissions and backup original files.
In the end you may want to go to /data/adb/modules/magisk_overlayfs and modify mode.sh to lock partition again (mode 2), this is done to avoid some apps detecting traces of modified system with Momo app.
Additionally I recommend undervolting GPU.
Thanks to @ragu24 for pointing at the right direction.
To do so:
Install konabess and select your GPU (should be in the middle).
Backup old image.
Then go to import/export.
Export your config (backup).
Import config txt that I shared.
Save GPU freq table.
And then repack and flash image.
After rebooting check the frequency table if the UV applied correctly.
Have fun!
Changelog
0.1 initial release:
Kill switch disabled
Applied Xperia Stream profile to Game Performance and camera
0.2 version:
Slightly raised screen temperature limit (it was lower in gaming mode)
Modified general camera profile (non stock app?)
0.3 version:
Disabled screen fps drop for other game profiles (unless screen itself is hot)
Returned kill switch (previous version will not stop unless other sensors show high temp)
Raised temperature till 64C for camera and game performance profile
0.4 version:
Less aggressive throttling for best performance (Game performance and camera profiles)
Raised temp to 66C for video recording and game performance profiles (endurance mode)
For other camera related profiles I limited temp to 63C
Switched modem to endurance mode on a game performance profile, however during long video recording modem may be temporary disabled to reduce device temperature
1.0 version:
Introducing modified "battery life preferred" and "balanced" profiles for Game Enhancer (Also thermal limit in custom settings should do the trick)
"Battery life preferred" temp limit: 57C, Max frequencies: 1267Mhz(Little)+1325Mhz (Big)+1728 (Prime)+492Mhz (GPU)
"Balanced" temp limit: 59.5C, Max frequencies: 1574Mhz+1651Mhz+2054Mhz+545Mhz
1.1 version:
Reworked game enhancer profiles to have dynamic frequency adjustment instead of aggressive throttling
Restricted limit for performance profile to 61C
Restricted limit for balanced profile to 58C
Disabled modem endurance mode for performance profile, since device doesn't heat that much anymore (back to stock change.cfg)
Made sure that underclocking kicks in instantly on balanced and battery safe profiles
Minor bug fixes
Also for xperia 1 iii with A13 ?
Pandemic said:
Also for xperia 1 iii with A13 ?
Click to expand...
Click to collapse
You have different frequencies and no Xperia Stream support, but we can use profile for endurance mode.
Share your config I will take a look.
V 0.2 Update
Slightly raised screen temperature limit (it was lower in gaming mode) and modified general camera profile (non stock app?)
0.3 Update
Disabled screen fps drop for other game profiles (unless screen itself is hot)
Returned kill switch (previous version will not stop unless other sensors show high temp)
Raised temperature till 64C for camera and game performance profile (same as endurance mode)
P.S.
Seems like Sony maxed out all the frequencies without any throttling and then just shut it it off after it reaches 55C during video recording. No wonder why it overheats lol
Thank you! just installed v0.3, you actually made me root my phone AGAIN just to enjoy this. wow.
i was wondering if i should keep stock and buy a stick for endurance mode or just root for free, and i chose the free and comfortable option.
ps. i also tried seeing what will happen if i flash different region firmware (54 on 72) - it seemed to work, and i could scan barcodes for e-sim cards, but unfortunately reception wasn't working with the different region firmware. now when i am rooted, i will see if it is possible to flash different MBN files to get VOWIFI working (LET+5G works)
Orof said:
Thank you! just installed v0.3, you actually made me root my phone AGAIN just to enjoy this. wow.
i was wondering if i should keep stock and buy a stick for endurance mode or just root for free, and i chose the free and comfortable option.
ps. i also tried seeing what will happen if i flash different region firmware (54 on 72) - it seemed to work, and i could scan barcodes for e-sim cards, but unfortunately reception wasn't working with the different region firmware. now when i am rooted, i will see if it is possible to flash different MBN files to get VOWIFI working (LET+5G works)
Click to expand...
Click to collapse
Haha, I rooted just to see if it will be possible to implement this mod and pure black background in apps.
Unfortunately you can't just buy any stick and enable endurance mode, device needs to be connected to some external device via usb/hdmi. It almost seems like a way to encourage people to buy compatible accessories.
As for different regions I don't think you can enable e-sim on the device that doesn't has the module. Also if you flash Japanese firmware you will have voice recording for calls, but nfc module will break, because they use different technology.
As for enabling VOWIFI it might be possible. You newer know if the difference is in hardware or just limited by software. For example I converted my XZ premium to dual sim by flashing firmware and replacing sim tray.
You can either experiment with newsflasher or manually.
With overlayFS you can "write" to system partitions(unless it's root folder like system or oem), I think I saw something related to connectivity in /product partition.
Just use unsin tool to unpack part of firmware in open it with 7zip.
In case a failure it's nice to have a bootploop protector module, or you can boot in safe mode to disable magisk and start over. However my mod will need reinstallation too.
Suggestion - a couple of changes to the throttle behavior.
this is how phone throttles after 20 mins of CPU test with a fan on the case. as you can see - no dips, very high performance.
however, this is how the phone behaves when there is no fan attached to the phone (and the phone is without a case):
this suggest that some throttling adjustment is in order, as playing games with this amount of throttle will surely be noticeable.
for reference, this is how the phone throttles on stock profile:
if we can make the temp more consistent and less frame drops - it will be great (not needing to use a fan as well)
EDIT - Throttling behavior from stock is from the original firmware. it should be possible to extract the thermal engine from the initial catches of the Xperia 1 IV and apply them to the current software (currently the phone throttles more than it did in the past, to around 170k points)
app is CPU Throttling Test
@Orof , thank you for your tests! Frame drops are unavoidable, that's the "kill-switch". Without it temperature will keep rising and rising, CPU needs to cool down somehow.
How many threads do you use in CPU Throttling test? I don't think default is enough, as with Burnout Benchmark I was able to trigger modem overheat warning when I disabled kill-switch.
I am working on the new version based on endurance mode with throttling at 57C and kill switch at 66C( max for endurance). It may restrict modem when the temperature will be high enough (Happened during 30 minutes recording [email protected]). Gonna do couple of tests and upload it.
New version is up!
There are two files inside archive now, same logic applies with replacing and setting permissions.
Annnd still hitting the kill switch for some reason (using the new files)
I wonder why. I wish the throttling was more aggressive so that the kill switch wouldn't be met, while still gaining more performance than stock (215,000 according to gsmarena)
*EDIT -changed the threads amount from the default value (20) to 60, still the same.
Orof said:
Annnd still hitting the kill switch for some reason
View attachment 5916741
I wonder why. I wish the throttling was more aggressive so that the kill switch wouldn't be met, while still gaining more performance than stock (215,000 according to gsmarena)
*EDIT -remembered yo change the threads amount.was testing the default value (20). How many did you test?
Click to expand...
Click to collapse
I used 20 threads.
Maybe you have higher ambient temp?
Also it seems that every device is different for some reason. Some people can film for 15 minutes 4k120fps, others see the thermal warning while just taking photos.
Did you try limiting frequencies with FKM?
Doom Slayer said:
I used 20 threads.
Maybe you have higher ambient temp?
Also it seems that every device is different for some reason. Some people can film for 15 minutes 4k120fps, others see the thermal warning while just taking photos.
Did you try limiting frequencies with FKM?
Click to expand...
Click to collapse
I reckon that the higher ambient temp is the issue here, though it doesn't mean that it throttling cannot be initiated sooner or harder to avoid the kill switch, for those who live in a higher temp locations
Will try limiting via FKM. Can already confirm that via the default perf setting (without the mod), score stabilize at around 170-180k with no sudden jumps, so it is something we should be able to do with a bit more tinkering.
Thanks for all the work! I really appreciate it.
Orof said:
I reckon that the higher ambient temp is the issue here, though it doesn't mean that it throttling cannot be initiated sooner or harder to avoid the kill switch, for those who live in a higher temp locations
Will try limiting via FKM. Can already confirm that via the default perf setting (without the mod), score stabilize at around 170-180k with no sudden jumps, so it is something we should be able to do with a bit more tinkering.
Thanks for all the work! I really appreciate it.
Click to expand...
Click to collapse
With aggressive throttling it will be very similar to kill switch. It will lower frequencies until device will slightly cool down and will do it again after it will heat. On stock it just happens very soon a major performance cuts that's why it's stable on the benchmark. Same can be achieved by locking frequencies with FKM for a specific app/game.
Doom Slayer said:
With aggressive throttling it will be very similar to kill switch. It will lower frequencies until device will slightly cool down and will do it again after it will heat. On stock it just happens very soon a major performance cuts that's why it's stable on the benchmark. Same can be achieved by locking frequencies with FKM for a specific app/game.
Click to expand...
Click to collapse
Thanks for the explanation, I understand now why it behaves this way on stock
I wonder if I can fine-tune the frequencies by editing the thermal-engine.conf (and maybe the change file as well) without needing to use FKM. already tried to make some changes to version 0.3 with no meaningful success. will have to dig deeper
Cheers!
Orof said:
Thanks for the explanation, I understand now why it behaves this way on stock
I wonder if I can fine-tune the frequencies by editing the thermal-engine.conf (and maybe the change file as well) without needing to use FKM. already tried to make some changes to version 0.3 with no meaningful success. will have to dig deeper
Cheers!
Click to expand...
Click to collapse
Try the uperf mod in combination with the modified thermal config file!
It's dynamically able to adjust the frequencies on the fly - just like FKM but dynamic! Combined with the higher thermal limits it should allow for a smoother experience
ragu24 said:
Try the uperf mod in combination with the modified thermal config file!
It's dynamically able to adjust the frequencies on the fly - just like FKM but dynamic! Combined with the higher thermal limits it should allow for a smoother experience
Click to expand...
Click to collapse
Thanks for the suggestion, but when trying to install it on the Xperia using Magisk, installation failed because "Taro is not supported". will try different versions of it ans report back
Orof said:
Thanks for the explanation, I understand now why it behaves this way on stock
I wonder if I can fine-tune the frequencies by editing the thermal-engine.conf (and maybe the change file as well) without needing to use FKM. already tried to make some changes to version 0.3 with no meaningful success. will have to dig deeper
Cheers!
Click to expand...
Click to collapse
You can try, just make sure to reuse the frequencies from the config like from game save profile.
Basically we have a choice either to have a higher performance with a little bit of drops or lower performance, but more stable.
On default profiles CPU just cust performance in half when it reaches 53C. Which happens like after 1 minute of CPU Throttling Test.
Anything below that reduction will not prevent CPU from building up the heat, but will slow it down. Without external cooling best you can do is to prolong that performance drop moment or castrate your CPU and "enjoy" stability.
Drops are necessary to keep device from going above maximum temperature (when I completely disabled thermal engine it easily went above 70C) because device sucks at getting rid of heat passively.
Main motivation to create this mod was to prolong video recording time, get rid of annoying screen refresh rate switch, as it causing flickering and squeeze a bit more fps out of emulators with prolonging the moment when the CPU gets castrated.
These synthetic tests do not reflect normal usage. If any game or app behaving like that it means poor optimization with an exception of emulators. It's up to users to configure each game to find a balance between stability and better graphics/more fps.
I'am planning to eventually edit balanced and battery safe profiles inside game enhancer, but don't expect miracles.
Meanwhile if anyone wanna contribute, you may lock frequencies with FKM and run the thermal throttling test on each, to find the one which is more stable, so I can use this data in modified balanced game profile.
Orof said:
Thanks for the suggestion, but when trying to install it on the Xperia using Magisk, installation failed because "Taro is not supported". will try different versions of it ans report back
Click to expand...
Click to collapse
I use this one - one of the latest
New version is up!
Basically it eliminates the need to have FKM, as balanced and battery life profiles in game enhancer will castrate frequencies as soon as possible , which will slow down heating (what the point of having maximum performance for a minute anyways? ) and result more stability.
Frame drops may appear sooner or later, depending on your ambient temperature, if you are using my undervolting profile, phone case (all my tests run in aramid carbon fiber case) and in general it seems that it's random for each device.
Battery safe profile
Balanced profile
Related
Welcome to the Perseus kernel! I thought it would be a nice catchname considering the Galaxy/Universe/Pegasus themes.
I'm trying to be more cutting-edge in terms of development in this kernel. In contrast to other kernels and philosophies of other developers, I don't believe giving the users more choice is a very smart thing to do. As such you won't find a dozen different governors or twenty different settings for this kernel. There is a optimal, or at least, most optimal setting on which the devices operate both in terms of performance and power management. For the average user this kernel will brings lots of benefits to battery life, screen improvement, fluidity and sound enhancements without having to set up any of the configurations.
The kernel comes with a configuration application called STweaks, and is installed automatically with the kernel. You will find all advanced options in there.
Don't be scared by the alpha denomination of the kernel, I'm just taking the traditional naming scheme where alpha designates feature development, beta is feature-completeness, and final will actually be when I'll actively stop developing the kernel. The kernel is very stable, and any bugs are fixed in hotfix versions (alpha x.y)
The kernel is also being maintained and released cross-device for the I9305 (S3 LTE), N7100 (Note 2) and N7105 (Note 2 LTE) and shares the same base-source.
Features / changelist:
Perseus alpha36.3 (26/04):
Fixed slice lookup issue on ABB: It's recommended you put your slices back to default before flashing if you changed them to borderline stability values. Please upgrade.
Perseus alpha36 (22/04):
Adaptive Body Bias control (ABB). (Experimental feature)
Body biasing is taking advantage of transistor body effect for binning the chip depending on its quality. In fact, this is used on the latest Samsung SoCs both for reducing power consumption and validating bad chips by adjusting their electrical characteristics.
The body bias is dictated by the voltage applied to the transistor gate (The usual voltages you're all used to) minus the voltage applied to the transistor body. The resulting bias can change the transistor's electrical characteristics in two possible ways:
Before reading on: A transistor's voltage and operating frequency is defined/limited mostly on its threshold voltage. Wikipedia has a neat visual representation of this; voltage must raise to a certain point for the transistor to be able to switch and operate. This threshold voltage can be highly dependant on temperature, influenced by the body effect, and defined by the manufacturing process. What we're doing nowdays with undervolting is to get as near as possible to the upper bound of this threshold voltage.
With that in mind:
Forward Body Bias
A FBB is defined when the bias of the gate voltage minus body voltage is positive, meaning the gate voltage is higher than the body voltage. This has the effect of reducing the threshold voltage. By reducing it, you can achieve lower voltages, or be able to clock the transistor higher. However the side-effect of lowering the threshold voltage is that you are sacrificing power leakage, meaning that the lower the threshold voltage becomes, the higher leakage current in the transistor becomes. This leakage power rises exponentially with a linear lowering of the threshold voltage. This is what is called static transistor leakage.
Reverse Body Bias
A RBB is defined when the bias of gate voltage minus body voltage is negative, meaning the gate voltage is lower than the body voltage. it has the direct opposite effect of FBB, it raises the threshold voltage thus you would need a higher gate voltage for switching, but however you also dramatically decrease static leakage.
What happens is that you want to use RBB when idling, and a reduced RBB, or even FBB at very high clocks.
Samsung currently uses this on top of voltage scaling to bin their chips. Here's an excerpt of the stock body biasing on the 4412 Prime chip (I'm using that one as an example as it has better adjusted ABB values over the Rev 1.1 chips).
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
To find out your ASV group: You can read out your ASV group in /sys/devices/system/abb/abb_info now.
I have rewritten the ABB scaling logic/driver for CPU, GPU, MIF and INT voltages.
In the current implementation, since it would be insane to have paired-up gate-body voltages divides the frequency range in several slices; even Samsung uses only three voltage ranges on the DVFS scale. I divided the frequency ranges as follows:
CPU: Divided into four slices, with frequency ranges of 200], 800], 1600] and ]1600 Mhz.
GPU: Three slices: 160], 533] and ]533 Mhz.
MIF and INT: Both only two slices with the bottom frequencies for each as middle-threshold.
As mentioned above, controls can be found in /sys/devices/system/abb/ and the entries are self-explanatory. You can also change the frequency slice limits per sysfs, however in STweaks I only included the voltages for each slice only for now.
Disclaimer
{ And that's about it in that regard. I have tried testing things over last couple of weeks, but I haven't come to a solid conclusion yet beyond what's presented by the stock characteristics: It's up to you people to do some advanced testing on the matter. My limited empirical testing in terms of voltages tells me it works as intended, but if a user with advanced measuring equipment would do similar testing to what I did back on the 4210 it would be perfect. }
zRAM: Switched over from LZO to Snappy compression algorithm, this provides much faster compression and decompression than the LZO implementation which was in the current kernel. I updated the Snappy libraries to the latest original CSNAPPY implementation, so this is extremely new.
Some kernel internal updates to speed up hotplugging and improve I/O latencies.
A correctly (Unlike basically every other kernel out there till now) applied load averaging patch regarding fixing a Moiré pattern in the scheduler load calculations which was floating around.
Fixed mono and equalizer switches in the sound engine. (Thanks to sorgelig for beating me to it)
Fixed led controls to behave correctly with user-space apps.
mDNIe digital brightness reduction:
You can now lower the brightness to basically nothing via this: it uses the mDNIe engine to digitally remove luminance from the RGB channel values, as opposed to reducing brightness via a proper backlight/display driver. The side effect of this is that you lose colour resolution somewhat, but is a practical and working method to reduce the too bright minimum values of our displays.
You have three configurables:
A reduction rate which you want to apply, this is the intensity of the darkening you want to achieve.
The take-over point; the backlight driver gets fed brightness values from 0-255 (In reality values below 20 have no effect). The take-over point is the point where the digital brightness reduction starts, on a reverse scale. The reduction is applied linearly from 0, (Full reduction taking place), to the take-over point (Zero reduction). The stock slider doesn't go below 20 in the interface, so practically the full reduction rate is never applied unless you use a third-party brightness controller app, just to keep that in mind, but in practice it doesn't matter.
Auto-brightness input-delta: This is needed because the stock framework is retarded in the values it forwards to the kernel, you can adjust this to avoid having brightness reduction when you don't want it on auto-brightness.
Somebody needs to edit config_autoBrightnessLevels, config_autoBrightnessLcdBacklightValues in framework-res.apk\res\values\arrays.xml to fix this.
Optionally, if you use a third-party app like Custom Auto Brightness which allows backlight values of down to 0, you can avoid this problem.
The register hook needs to be enabled to be able to use this function.
Increased the maximum brightness by 50 candela: the manual controls were limited to 250cd as maximum as opposed to 300cd which was only usable during auto-brightness, and unusable for any third-party apps.
Unaligned memory access throughout the kernel when applicable.
Switched over to GCC 4.7.3 Linaro toolchain for compiling.
Perseus alpha35 (06/04):
Further rewrote the in-kernel audio controls:
Threw out the old detection methods for something more robust.
This particularly enables non-cellular applications such as Skype, Viber, and so on to be detected correctly. A "calling" state now includes any and all use-cases where the audio is outputted via the phone's earpiece. This fixes microphone levels for such apps to correctly use the calling sensitivity value.
Added microphone level for camera use, this state is enabled whenever a camera stream is active. It should give more options into adjusting things to your likings.
By now the sound engine has only little similarities to Boeffla, any bugs and feedback now go directly to me.
Developers only: MHS: Added a new small tool for tracking media use and reporting it to other in-kernel drivers. Capable of detecting video recording, decoding and camera streams for now. See commit for more info.
mDNIe control changes:
Removed several controls in STweaks simply because people misunderstood them or misused them, or they simply had no rational use.
Video detection, now with the help of MHS, is no longer limited to the stock video player. Any video players using hardware decoding will now be able to make use of edge enhancement, HDR and DNR, this includes any web-based players and the YouTube app.
Custom LED controls implemented; Exposed most variable controls for the notification LED via sysfs and STweaks (LED tab). :
Control LED brightness. Currently the OS dictates, depending on brightness detected by the light-sensor, wether to run the LED in a low-power mode or in a high-power mode, you can now set brightness for both.
Blinking control, this is basically the shape of the wave-pattern that the LED blinks in, you have several controls, best described the data-sheet description:
The fade-in time period is TT1 in the graph, while the fade-out period is TT2.
Slope (1/2/3/4) detention time represents DT1,2,3,4 in the graph, it controls how "steep" the four different curves are.
The LED fading checkbox simply switches between having the detention times controlled by the sliders to having them to 0 (Stock blinking behaviour).
Increased default zRAM size to 400mB. This won't override your STweaks setting, so only new users will see the new value. Others should please adjust the value manually to your liking.
Sources:
https://github.com/AndreiLux/Perseus-S3
Credit and thanks:
gokhanmoral, netarchy, and anybody credited in the commits.
TL;DR: before flashing aside from known issues in the second post.
This isn't an AOSP kernel. I won't work with CM and AOSP derivatives.
DOESN'T WORK ON SAMSUNG JELLYBEAN 4.2.1 ROMS.
Known issues [Updated 02/12]
None
Older changelogs
Perseus alpha34 (22/03):
Updated sound engine. Based on Boeffla (Andip71)sound but custom fork with rewritten system interface and some other code re-factorings.
Should fix all FM Radio issues.
Brings us saturation prevention for the equalizer.
Privacy mode.
Microphone level control
You now have control over the speaker equalizer via sysfs, please visit /sys/class/misc/wolfson-control/ the controls are self-explanatory.
I removed the equalizer pre-sets from STweaks, if you want, set them manually:
Bass-extreme: 12 8 3 -1 1
Bass and Treble: 10 7 0 2 5
Treble: -5 1 0 4 3
Classic: 0 0 0 -3 -5
Pleasant for ears: 4 3 2 3 1
Eargasm: 12 8 4 2 3
I recommend HeadphoneAmpControl (thread - Play Store) for controlling the volume directly on a hardware level; it will overwrite the digital volume of the OS and use the hardware amplifiers only.
Enabled ZRam by default with disk size of 200mB and swappiness of 90%.
The ZRam control is found in the I/O Tab in STweaks. Set it to 0 to turn it off completely, any other value to turn swap on. Changing value takes about ~10-20 seconds depending how loaded the disk is with swap pages so don't piss your pants if it doesn't react immediately.
Applied a requested patch which allows PCs to be booted off from the phone storage.
Perseus alpha33.2 (27/02):
Master profile is correctly calibrated.
Detailed calibration report: Download
Advanced colour management report: Download
All thanks goes to Slimer777 for his excellent work.
Perseus alpha33 (26/02):
Revamped and hopefully final version of mDNIe controls:
The controls work now on two levels: First we have a master sequence that overrides any and all of Samsung's settings; currently this version is released without calibration, however in the next minor version it will be updated with proper professional screen calibration. See the Note 2 thread to see what to expect here too. The master sequence is calibrated to sRGB norms on a precision level equalling and even surpassing the iPad3/4.
The master sequence works as as the calibrated base; for people not wanting to bother further with any more controls, you simply enable this and you're done.
Second part is the register hook, it catches effect values and modifies them by applying delta values available as controls in STweaks and in /sys/class/misc/mdnie/hook_control/.
Leaving both these options will give you Samsung's default values, plus the black crush fix.
The register hook, while used on Samsung's profiles, is not capable to alter effects which are not integrated in that screen profile's value sequence, the "Movie" profile for example lacks some effects present in the "Dynamic" profile. The same is valid when having different scenarios, the "Camera" scenario will use different effects in its base than the "UI" scenario. To fully explore all possible effects, use the Master profile as it integrates all effect values known.
Each control has a master kill-switch which enables or disables the effect. This varies by profile and scenario, so you have control to only "toggle" the switch, whatever its state may be in.
Digital noise reduction - Reduces and flattens out grain. Advanced controls are found in the hook_control folder with the dnr_ prefix.
High dynamic range - A HDR effect which brings out details in dark and extremely bright scenes.
Digital edge enhancement - An edge enhancement effect. What we previously called "sharpening". Divided in controls for radius, amount and threshold. Read the Wikipedia page for more information. More advanced controls found in the sysfs under the de_ prefix.
For the above three effects, scenario consideration is taken into account. You can enable/disable them depending when you want it to be applied. Please be aware only the stock applications trigger the scenarios. I will try to enable at least the video scenario depending on when the hardware decoder is active in the future so that they are enabled also in third-party video players.
Chroma saturation control - Same as in previous version but with fixed labels.
Colour temperature control - By default this is disabled on all profiles, however, if your screen has a tint to it, this is the first control you should try to fix as it alters temperature on all channels.
The SCR controls are colour channel filters working on the Red, Green, Blue, Yellow, Cyan, Magenta, White, and Black channels.
Imagine the controls as manipulating the corners of the RGB cube:
(Credit to Wikipedia for the graphic)
By controlling the RGB coordinates of each corner/channel we can mould the cube into a different shape. At the same time the cube is projected onto a hexagon; the perimeter of the hexagon represents the colour hue, the radius of the hexagon from the middle represents chroma. We can use the chroma saturation controls to "push in" each corner of the cube, while moulding the corner's directions with the RGB controls. The RGB coordinates can be transformed into the HSL space space if needed, however I didn't include this function yet as I don't feel the need for it.
STweaks has controls for the RGBYCMW channels, the K (Black) channel I left out because it makes no sense in altering it, but can be found in the sysfs folder.
Several controls have a "factory setting" switch, this are the burned in-hardware values for some controls, they overwrite the controls themselves.
Additionally to the controls exposed to STweaks, there are several other effects and modifiers exposed in the sysfs interfaces. This also includes the gamma curve controls for levels 0-255 in steps of 16.
There are also some additional unidentified configurables which I wasn't able to properly give a name to or had no effects: Dithering, ABC (Seems to give a gamma brightness boost), SCC, UC, and MCM (Colour temperature) configurables whose exact effect isn't documented.
Perseus alpha32 (29/01):
Charging control implemented. This is my own version.
Charging currents:
Charging currents are dictated by input and charging current limits. The input current is the current flowing into the device through the USB port at 5V. The charging current is the current delivered to the battery at usually 4.35V. The device can have a higher charging current than input current because of the voltage differential, usually a 15% discrepancy. You can also have much higher input currents than charging currents, this can be useful when you are using the device in situations like gaming and charging your battery at the same time, provided your charger actually can provide the power.
There are 3 USB charger type categories: DCP / Dedicated Charging Ports which also includes AC chargers, but also special USB plugs; SDP / Standard Downstream Ports which usually includes almost all data enabled USB ports, and CDP / Charging Downstream Ports which includes also data enabled USB ports but which are designed to provide more power, usually on newer laptops where the USB port has a lightning logo next to it. More info here. - Technical explanation here.
Charging logic:
Stable margin removal option. The charger chip is capable of detecting unstable charging sources; it dynamically reduces the input current in 100mA steps until it detects a stable voltage input [We don't have the charger chip datasheet, so the technical explanation is a bit blurry here on how it decides that it's unstable]. It further reduces it by 100mA as a safety margin, you can disable this now.
Complete disabling of unstable power detection. This simply ignores unstable power sources and leaves the input current limit at its set up value. This will fix charging problems people have been reporting. However, please use it at your own risk, the S3 chargers which have had these symptoms clearly have some issue in their hardware so you might actually kill them with this option enabled as there is no protection from the phone's side anymore.
The actual input current limit can be read out in /sys/devices/platform/samsung-battery/power_supply/battery/current_max, so you can see the real limit there, it's the closest thing we have to the actual charging current on stock values since there is no hardware to read out the live currents.
Voltage control:
Hard voltage control: 4.20, 4.35V, and 4.40V charging voltages are available. This is included for anybody running on third-party batteries, whom most of them have a 3.7V battery chemistry as opposed to the 3.8V on the stock battery. These batteries should be charged at 4.2V instead of 4.35V.
Soft voltage control: As opposed to the hard voltage control which is the voltage which the charger chip provides to the battery while charging, the soft-voltage is the battery voltage itself. 3.7V batteries have a top-off voltage of 4.2V and 3.8V again 4.35V. The default limit on the stock battery is 4.30V before the charger logic stops and considers the battery as full. This is also merely provided for 3rd party batteries which should be charged at lower voltages. If you overcharge your battery beyond these what are safe considered voltages, such as raising the default 4.30 top-off voltage to the design 4.35V or even higher, you are running into the risk of damaging the battery or even causing it to melt-down. Use at your own discretion.
mDNIe sharpness and RGB/YCM chroma saturation control in STweaks:
I started implementing sharpness control in STweaks and went a bit over-board instead of a simple checkbox; You now have controls over the mDNIe registers as a delta offset value compared to the stock register values. I'm applying the offset to all mDNIe profiles and scenarios which have the specific post-processing effect active in that specific scenario. Meaning, that you start with the default profile; Dynamic / Standard / Natural / Movie and have the delta offset applied on top of that.
Sharpness delta. This is what brought most of the quality difference in hardcore's original tweaks. You can now fine-tune it to your own taste, and also take into regard that it produces a different effect for each screen profile while having the same delta - the base values between the profiles are different.
DE control - I don't know what this actually does and I couldn't discern much difference between the values, but it used to be disabled in hardcore's tweaks.
Chroma saturation control: This is composed of 2 values for each RGB/YCM channel. See the Munsell color system for a visual representation of the values controlled here. The chroma curve control describes the curve weight based on chroma intensity, the chroma gain is the chromatic gain that is being applied on the respective channel. Chromatic saturation weight is again another multiplier for all channels combined. I have not managed to properly identify the chroma grey threshold and its effects.
Basically this is like an RGB control on steroids, and enables you to tune your screen to your own liking and calibrate it as you wish. Please note that not all scenarios in the profiles have chroma saturation effects, the Movie profile for example has no effect applied to the UI so chromatic control has no effect on it.
I also want to state that the above are my deductions and theories on the descriptions of these controls, I'm not familiar enough on colour theory to be able to confidently say that these descriptions are correct, and the controls are a work-in-progress for now. Experts are welcome to contribute here.
Front buffer early suspend delay option for those who have issues with the CRT animation.
Did some refactoring on the Mali drivers and fixed a bug which may have caused less capable undervolting than the stock implementation.
Perseus alpha31 (09/01):
Removed my own security fixes and replaced them with the official Samsung one. I guess it can now be disclosed: exynos-mem was only one of multiple entry-points for the memory exploit. We discovered the s5p-smem exploit ourselves back in December but kept it quiet, I fixed that one back in version 29.2 without mentioning. Nobody was secure from a smart exploiter up until then, SuperCurios or Chainfire's software fixes are also just patching a single hole in what is a Swiss cheese. Kernels >v31 and beyond stock LLA are now the only truly protected ones.
Samsung's fix for the sudden death syndrome (SDS) included. It is caused by eMMC failure on phones with VTU00M internal memory chips with revision 0xF1. You can check your phone with the "eMMC Brickbug Check" in the Play Store (Ignore the message if it says you're not affected, the type and revision is what matters). The patch is a firmware soft-patch that is applied on every boot and MMC resume, it is not a permanent fix. You will need to stay forever on kernels which include the patch, this also includes updated recoveries and their embedded kernels.
Some other minor MMC changes extracted from Update 7 sources.
Harmonized some mif/int max voltages with the Note 2 limits.
Perseus alpha30 (06/01):
Internal and memory voltage control. This is the first and only working implementation out there. Memory interface voltage is exactly what it the name implies, the voltage on the chip-to-chip interface from the SoC to the memory chip. Internal voltage is the whole SoC voltage excluding CPU, GPU, and the MIF. This includes all auxiliary function blocks such as the ISP/Image signal processor, camera interfaces, I/O interfaces, display controller and the MFC/Multi function codec hardware video de-/en-coder.
Internal voltage respectively memory voltage table is found in /sys/devices/cpu/busfreq/ as int_volt_table or mif_volt_table
The frequencies are defined as OPP's (Operating performance points), internal frequency and memory frequency (And voltages) together as a pair form an OPP. If you want to change the voltages through the sysfs files, keep in mind how you change them. MIF voltages are stored independently with each OPP step. INT voltages are stored in respect of their frequency key.
Default OPP steps are: 400200, 267200, 267160, 160160, 133133, 100100. The first three numbers represent the memory frequency, the other three the internal base frequency. For example 267200 means the memory interface is at 267MHz (533MHz DDR) and the internal frequency is 200MHz.
The voltages in STweaks are sorted out through some magic and are frequency unique, I recommend using that for controlling them.
Busfreq logic control added into STweaks, this includes all the already available configurables in the stock kernel with added explanations and I supplemented it with a sampling rate parameter.
Some minor source updates from Samsung regarding some new sensor drivers.
Replaced pegasusq's runqueue detection logic with a new more superiror and precise in-scheduler collection logic, I found that the real runqueues are much less than what was previously reported. This should help a lot with hotplugging.
Enabled AFTR by default since we are now running very often in single-core mode. Keep in mind this mode is WFI Idle + LPA + AFTR.
Fixed a kernel bug which was eating up randomness entropy. This is related to that whole seeder business - please don't use any of those fixes. I also disabled virtual addresss randomization and at the same time disabled entropy generation from the block layer, which should avoid I/O overheads.
Perseus alpha29.2 (24/12):
Another minor (major) release due to security. Please update.
I screwed up something touchscreen related in v29 that disabled Flexrate requests, fixed now.
Changed Flexrate requests so that they don't scale down in their sub-samples anymore. This should improve fluidity.
Perseus alpha29 (18/12):
I'm doing a quick release because of the security fix, not very feature rich.
Fixes the exynos-mem security hole. This is my own fix and will not break camera. Read about it here. You don't need to use Chainfire's or Supercurio's fixes, in fact, you shouldn't use them because of the camera.
Updated Wifi drivers.
Added GPU utilization control to sysfs and STweaks.
Changed default GPU thresholds to more relaxed values (75/17)
Added block device read-ahead control to STweaks. Additionally set the default read-ahead for internal memory to 256kB and 1mB for SD cards.
29.1: - Reverted the Wifi drivers back and did some CMA adjustments to see if that fixes some random reboots of people.
Perseus alpha28 (13/12):
28.1: I reverted the striked out changes due to exFat. I changed my mind due to demand. I apologize for the chaos.
On your SD card showing up as damaged: it is not.
I made a decision in terms of exFat compatibility; either I advance the kernel with newer upstream Linux versions or stay back and keep compatibility with the exFat modules. While I have nothing against proprietary modules or such, not being able to adapt them to the kernel is not optimal. You can format your cards to FAT32 or ext4 without much issue. Please back up your data and format your card accordingly before flashing v28.
[*]Updated the block system to Linux kernel 3.3.
Introduced FIOPSv2, ROWv4, ZEN, BFQv5 as new I/O schedulers;
FIOPS is the new default scheduler, it's a CFQ like fairness scheduler optimized for solid state storage. ROW should be the actual better performer here as it has superior logic, but I didn't set it as default because of some lags when installing applications. ZEN is just a mix of SIO and Deadline and nothing special. BFQ seems to underperform. I recommend the first two over everything else, and added the latter two just for comparison's sake.
Added dynamic Fsync control (Faux123). It disables Fsync only when the screen is on. Enabled by default (Fsync off).
Changed some logic on when the adaptive scaling voltages are applied in the kernel init sequence. This fixes GPU voltages not being applied at boot and also fixes the wrong default voltages being displayed in STweaks.
STweaks tab for I/O with scheduler selection for each device block and also dynamic Fsync.
New script side feature in the uci.sh framework: When inserting an override.profile file into the profile folder (/data/.perseus), the entries in the override profile will supersede the ones in your default profile. You can use to make CWM zips to turn off set at boot flags or to share targeted settings with others. The override is applied once at boot after which the profile deletes itself.
Perseus alpha27 (02/12):
Sources updated with various updates from N8000u1 base. Included are following important changes;
CMA memory allocation has been altered and page handling in the kernel in regard to CMA affected pages has been dramatically improved, this should fix the high load of the "migration" process users have had since initial Jellybean kernels.
Updated wireless drivers.
Adds a delay to SD Card host controller power-down, which I assume is to prevent some corruption. There is a specific change to Toshiba 19nm manufactured SD Cards, these are mostly the latest SanDisk 64GB cards. Together this may fix issues users have had.
Updates the camera interface, Video4Linux and Jpeg2x drivers and this fixes compatibility with 4.1.2 ROMs. Backwards compatibility is retained.
Other updates which are more transparent to the end-user.
New PegasusQ logic:
- We now have additional conditionals on the hotplug logic which checks the total load across all cores and is able to bias towards a specified core count if the load is low. This is useful because previously we could have had frequency spikes and lots of low-load threads triggering a hotplug-up while in reality it wasn't needed. The core count is more biased on keeping 2 cores online in most cases now unless really needed.
- The way freq_step is handled has changed. We now take the remainder of load space above the up threshold and dissect it into three slices each having different frequency increase step sizes. The first two slices are each of up threshold differential size, lop-sided towards the lower end of the load scale. We specify the slice size and freq_step delta in regard to the original freq_step.
- A new fast-down scaling logic; if frequency is beyond a certain threshold, we take a heightened up_threshold value solely on the down scaling logic to scale down more aggressively from the higher frequencies.
STweaks. This is my custom implementation of the kernel side, based on Gokhan Moral's initial implementation.
- CPU overclocking and voltages interface.
- Configurables for all CPU governor settings.
- GPU overclocking and voltage interface.
- Interface for audio enhancements.
Perseus alpha26 (14/11):
Updated MTP drivers back to the newest version. Fixes some inconsistencies which some people had.
Further increased MMC command timeout from Linux default 300ms to 3s in trying to finally squash errors and "unexpectedly removed SD card" after resume.
Ported Gokhan Moral's mDNIe interface and also added colour tone modes on top of the scenarios. System interfaces are found in /sys/class/misc/mdnie . Input syntax is the same as the output syntax, or, single register-value pairs as a single line in the output format, except 0xFF which is a terminator value.
Increased default sampling rate down to 30ms from 50ms for a bit more fluidity.
LTE devices only: Updated some power management functions on the MDM modem from latest sources; this will drastically decrease the amount of wakelocks on mobile data and improve battery life.
26.1
Disabled net_os_rxfilter_add_remove userspace/ROM filter management in the Wifi driver to prevent the operating system of enabling unwanted pass-through multicast and broadcast filters while in standby.
Perseus alpha25 (23/10):
Raised and fixed USB, MISC charging rate to 900mA.
Enabled OTG car dock, smart dock and music dock charging. Alternatively this can be triggered if you short pins 4 and 5 of the USB connector with a 40.2kΩ, 64.9kΩ or 619kΩ resistor.
MTP fixed on OSX devices.
Fixed ROM power savings feature, this was originally broken because of the addition of overclocking, and the same interface that Samsung uses for limiting CPU speed in power savings mode also limits the max frequency to factory defaults. This is now fixed and powersavings mode will throttle to 1000MHz.
Fixed mis-configuration of the default audio settings to improve sound quality, sorry about that.
Ripped out the old GPU scaling mechanisms and scaling logic and replaced it by something new.
The old mechanism was getting overly complicated and was a remnant of the Galaxy S2 where we merely had 2 frequency steps originally; this was fine then, but isn't anymore today. The threshold fuçkery was confusing to a lot of people and people generally misconfigured their settings with inane values.
The new scaling logic follows a more CPU governor-like approach: Scaling up logic is basically the same as before: the GPU will scale up to the next frequency step when the load reaches a certain threshold. Up-scaling takes place step by step. The up-scaling threshold is now global and a single value applies for all frequency steps.
Scaling down in the new logic resembles more like the ondemand method; The scaling down takes place when the load goes under a certain threshold. This threshold is dictated by the up-threshold minus a down-differential. By default they are 90 and 10. Triggering this condition we scale down into a dynamic frequency target capable of accommodating and dictated by the load level. In plain words, we can scale from max frequency immediately down to the lowest one. This will improve power consumption.
Ripped out the old GPU control interfaces and rewrote it with something new to accommodate the new logic. Your old scripts won't work anymore.
We now have 10 frequency steps to the user's disposition; defaults are: 54 108 160 266 350 440 533 640 733 800.
The new system interface targets can be found in /sys/devices/system/gpu/ .
- freq_table outputs a list of the current frequency table. You can use this interface for configuring the frequencies themselves in two ways:
Pair-wise target setting: echo 533 500 > /sys/devices/system/gpu/freq_table will change the 533 step frequency to 500.
Whole-table echo: echo 54 108 160 266 350 440 500 640 733 800 > /sys/devices/system/gpu/freq_table
In the above example you end up with the same end-result over the stock settings.
Valid clock frequencies are as follows: 54, 108, 160, 200, 266, 275, 300, 350, 400, 440, 500, 533, 600, 640, 666, 700, 733, 750, 800.
- volt_table outputs the voltages to the corresponding frequencies.
Pair-wise target setting: echo 533 1025 > /sys/devices/system/gpu/volt_table will change's 533MHz's voltage to 1025mV.
Whole-table echo in the same format as freq_table. Valid voltages are 600mV => x <= 1200mV.
- thresholds sets the two global threshold settings. echo 90 10 > /sys/devices/system/gpu/thresholds . Remember that the first is the up-threshold and the second is the down-differential. The down differential may not be higher than (99 - up value).
- min_freq and max_freq set the limits of the current DVFS policy. By default we're scaling from 160MHz to 440MHz (Same as stock).
echo 533 > /sys/devices/system/gpu/max_freq will enable the top limit to 533MHz and basically overclock the device.
echo 108 > /sys/devices/system/gpu/min_freq in the same way sets the lower limit.
25.3:
- current_freq shows the current frequency. This is if somebody likes to make a monitoring app or something.
- time_in_state shows the time spent in µS on each frequency step. Echo 0 to it (by default disabled) to disable it, 1 to enable monitoring, and any other numerical value to reset the timekeeping back to 0.
Perseus alpha24 (09/10):
Galaxy Note 2 source and kernel merge. Various platform fixes included from patching up from update5.
Fixed Mali GPU interface bugs relating to staycount, and lowered undervolt-soft limit down to 600mV.
5 step GPU scaling, for now. Change your scripts.
Fixed black crush on the display. Vastly better black levels are now of order.
Perseus alpha23 (27/09):
Changed some auxiliary CPU clock dividers for frequencies 1600,1704,1800 MHz. These frequencies should use less power now and also should be more easily reached with more stability or lower voltage depending on your device.
Fixed CPUPower driver (Back from alpha20); this will now skew the reported processing capacity of CPU0 in the lower frequencies up until 500MHz to be 8 times greater than CPU1-3, what it does now is that the scheduler will even more migrate tasks onto CPU0 to avoid idle wakeups on the remaining CPUs, resulting in increased power efficiency. For high load > 500MHz, the driver reverts back to the default power configuraitons.
Reset the regulator configurations to their physical minima; you can now undervolt to 600mV on the GPU. Sorry I missed this before.
New feature: Dynamic Screen Frequency Scaling.
This decreases the display controller frequency in tandem with the CPU speed. Usually when you have low activity on the screen; i.e. low re-draw rates, then you mostly also have logically low CPU load. I wrote a scaling mechanic to switch between high display frequency (60Hz), and low display frequency (40Hz) in accordance to CPU scaling. This is tied in in the CPUFreq governor, in this case PegasusQ. We have three new governor configurables found in /sys/devices/system/cpu/cpufreq/pegasusq/ (Or alternatively just use SetCPU):
lcdfreq_enable: Enables or disables the mechanic, disabled by default.
lcdfreq_kick_in_down_delay: The amount of samples to wait on below the threshold frequency before entering low display frequency mode. Default value is 5 for now, a.k.a. in most cases 250ms unless accelerated flexrate is active on low load (fingers touching the screen), then depending on situation it might get as low as 62.5ms.
lcdfreq_kick_in_freq: The frequency threshold below which the low display frequency kick-in will be active. Default is 500MHz, and should probably stay as such, setting it higher will cause lags as we'd be using 40Hz in an interactive situation.
For the curious: I made a rudimentary time_in_state state accounting sysfs in /sys/devices/platform/samsung-pd.2/s3cfb.0/graphics/fb0/lcdfreq/time_in_state for testing purposes. Currently it shows wrong time values for 60Hz as the driver gets initialized before the high resolution timer, and I'll fix that later, but the 40Hz time statistics are correct.
Notice: There will be now conflicts between this and user-space controlled TwDVFS service/app. The service would limit screen frequency to 40Hz while using the camera app, this will be now overridden. I also thought the service would do more but I could not find it scaling for anything else than the camera, so it's pretty much useless in my mind, and you could theoretically remove it.
Feedback 23.3: This feature causes flickering on bright colours and low brightness. Enable it at your own will.
Changed the functionality to boost to 60Hz on any touch interaction, regardless of CPU speed.
Please provide feedback on fluidity and battery life.
Perseus alpha22 (22/09):
Update to update5 source code. Only compatible with Samsung Jellybean ROMs.
Stacks with my previous memory changes: total memory: 857mB for now.
Implemented timer slack controller.
Backported the scheduler NoHz load computation fixes, this should dramatically improve PegasusQ's hot-plugging decision making.
Further reduced Mali sampling rate down to 50ms and changes the default thresholds to more aggressive power savings and clear-cut scaling. Removed 10ms regulator switching latency. I measured a 10% battery improvement in GLBenchmark 2.1 Egypt Battery - 50% Brightness 60 FPS.
config.gz support.
Alpha21 is the same as above but without update5 and for ICS. This is the last kernel for ICS, I'll not longer support it.
Perseus alpha20 (9/09):
Gökhan Moral's port of Voodoo Sound implemented. Currently no configuration interface is available, so if you wish to play with the settings, refer to the sysfs interfaces in /sys/class/misc/scoobydoo_sound/ . If you wish to change the device name, you must do echo 0 > /sys/class/misc/scoobydoo_sound_control/enable , followed by an echo output to the same file with the target device driver name. You can use this to change the device path to /sys/class/misc/voodoo_sound/ and sub-sequentially make a certain configuration application work. Please do not ask me for support on the latter. You can disable the sound modifications completely by the same method, by of course not re-enabling it afterwards.
Changed the Wifi packet filter to block out all but mDNS multi-cast packets.
Increased mmc timeout for bad quality SD cards.
Perseus alpha19 (1/09):
Updated Samsung source base up to update4, includes changes to the Wifi driver and various other small fixes
Added ARM topology support for the scheduler to be able to use sched_mc levels. This should increase cpu idle power consumption by decreasing idle wake-ups. For the moment disabled by default, and cpu_power doesn't seem to correctly work.
Swap support.
mDNIe sharpening improvement, courtesy of hardcore.
Decreased Mali utilization timeout to 100ms down from 1s which improves reaction time on instant GPU loads (Lock screen is best example).
New valid GPU frequencies : 54, 108, 160, 200, 266, 275, 300, 333, 350, 400, 440, 500, 533, 600, 640, 666, 700 Mhz
Increased user-space memory by 48mB to have a total of 825mB useable RAM; this comes from reduced DMA memory spaces on the part of:
- The Mulfi Function Codec a.k.a. the hardware decoding and encoding unit memory space from 50176kB to 28672kB
- The camera interface imaging subsystem from 12080kB to 10240kB
- The front-camera firmware block-space from 15360kB to 14336kB
- The ION heap size for the Video4Linux driver from 71680kB to 48128kB
In the case of the ION/V4L and MFC heap sizes I determined it by setting a benchmark for all the HD sample videos listed here to not have any detrimental effect before and after the changes. Below 41mB is the size for which the Planet Earth birds scene at 1080p high profile 4.1 40mbps video starts to lag. Keep in mind that there is no way this would be considered normal quality as this is basically un-recoded Blu-Ray quality and most videos are vastly under this bit-rate.
I note that I also haven't found any detriment in use of the cameras including the modded 30mbps camera quality.
Disabled the Kies daemon, I see no point in it and it uses up memory uselessly. Obviously Kies won't work any-more, if you want you can start the service yourselves manually.
Perseus alpha18 (11/07):
Updated Samsung source base up to update3, includes various fixes to fuelgauge battery reporting on full charge, MHL code, video media drivers, Wifi driver updates, gyroscope, MAX77686 battery charger changes, increased max display brightness, a buttload of LCD panel changes, and changes to the pixel refresh rate driver (This thing is controlled by the TwDVFSapp by the way and decreases screen power consumption at runtime).
ro.secure=1 again now but with an insecure adbd as root included.
LFB ramdisk.
Compiled with Linaro 4.6.2 and some higher level optimizations.
Keep in mind that running the new kernel on older ROMs can cause some funny behaviour, so update your ROM if so.
Perseus alpha17 (9/07):
Rewrote flexrate request code for pegasusq: I apologize for releasing the previous version in the state that it was, shame on me.
Now upon receiving a flexrate request and active ones, the governor delays hot-plugging sampling logic so that accelerated sampling is being taken into account and hot-plug sampling is normalized for the standard sampling rate. All sub-samples are being averaged into a normal sized sample at the end of the normalized period. This no longer interferes with the runqueue read-outs as they were being reset too fast and generally accelerated hot-plugging in a bad manner.
Changed touchscreen flexrate requests to 12500µS sampling rates over 4 periods to synchronize with the default pegasusq sampling rate.
I consider this chapter to be done and a success as far implementing flexrates as a viable and working alternative to touch-boost to increase responsiveness without having the bad battery-life side-effects of the touch booster.
Performance governor is now core-aware, previously as no other hot-plugging logic was available, the governor would start with whatever number of online cores were available at that time and stay like that. This made Performance useless for it's designed purpose, that being bringing maximum performance. It now brings up all available cores online upon start and turns all additional cores back offline on governor stop. It is now by far the best and consistent governor for benchmarking.
Removed unused cpu_freq_up, cpu_freq_down, and several other flexrate related governor parameters in Pegasusq as they were either not used, or senseless.
Default Pegasusq parameters changed:
- Sampling-down factor reduced to 1 from 2, this caused reduced sampling speed upon reaching maximum frequency. It now scales (possibly down) faster.
- Frequency steps reduced from 40% to 21% of maximum frequency, this causes it to scale in 300MHz steps for the default maximum policy of 1400MHz. As we now have flexrates to scale faster I did not notice any negative effects on performance and this should help battery-wise on load-"spiky" applications, and in general.
- Increased runqueue-length thresholds for the hot-plugging logic by a flat 75 for all conditions. In my opinion and experience they were too low and caused to keep the cores needlessly online. This now reduces for "average low" use the online-time of the third core considerably.
- Increased the hot-plug frequency conditions for the 4th core.
Updated the kernel from upstream to 3.0.36.
Memcopy and string function improvements, won't bring any noticeable differences.
Compilier optimizations (Roughly the same as Ninphetamine's) are now in. VFP uses the NEON libraries now. I couldn't measure any increase in any synthetic benchmarks with this though.
LFB exFat modules.
Perseus alpha16 (3/07):
Disabled touchscreen touch booster; this previously locked the CPU frequency at 800MHz, memory interface to 400MHz and bus frequency to 200MHz at any time the finger touched the screen.
Implemented flexrate capability into pegasusq; additionally added a frequency threshold above which flexrate requests are ignored. Currently this is set at 800MHz but is configurable in the governor tunables.
Enabled quality of service requests in the touchscreen driver, this currently triggers a flexrate request at a sampling period of 15ms over the governor default of 50ms, and over 5 periods, giving 75ms of heightened reactivity. It also sends a direct memory access throughput quality of service request to the the linux power management quality of service interface to guarantee a 266MHz bus frequency for 142ms. Still need to check if that the last part works correctly.
Perseus alpha14 (21/06):
Only Mali platform changes.
Remove Samsung integrated checks on in the Pegasus platform that prevented the GPU control interfaces to work. Overclocking, undervolting, and the rest now properly work.
Removal of the CPU frequency lock to 1200MHz if the GPU is at 440MHz, this is excessive as 3D load heavy applications usually do not tax the CPU that far, and is an unnecessary power consumption burden.
The thermal control unit temperature throttling causes to fix the voltage to a fixed value when throttling is in place; this is useless considering frequency is not limited, making the whole thing senseless. Thus removed.
Perseus alpha13 (20/06):
Rebased sources on a Linux branch for commit completedness. All commits reapplied and cleaned. New repo.
CIFS included as module
Busybox removed. This should be part of the ROM.
Perseus alpha12 (14/06):
Added enhanced init.d support as per dk_zero-cool's implementation.
SHA-1 improvements
Added exception to the module loading logic for the exFat driver module thus making it work. (Credit to gokhanmoral)
Perseus alpha11 (10/06):
ro.secure=0
Recovery renamed as busybox in /sbin. I'll compile a proper busybox later on, or remove it alltogether when a recovery with autoinstall is released by CF or somebody else.
Perseus alpha10 (8/06):
Overclocking up to 1800MHz. Voltages in ASV table are somewhat scaled up until 1600MHz, after that you're on your own and have to optimize yourself.
Intel claims maximum sustainable safe voltage for 32nm HKMG to be 1.4V, above that may cause electron migration to the silicon and permanently deteriorate your chip. 1700 and above only for avid overclockers and benchmark freaks. Credit to tvanhak for playing lab rat with his phone.
Samsung frequency limitation removed to scale above 1400MHz, full credit goes to Gokhanmoral for finding this hack in the kernel as it is in a very sneaky location.
Perseus alpha7 (5/06):
Reduced regulator voltage initialization minimum to 600mV, you can now undervolt that far. Be aware of crashes.
Added SIO scheduler
Some network and CRC related patches
Perseus alpha6 (4/06):
UV_mV_table support, apps like SetCPU work now.
If you have a voltage set at for example 1187500µV the output will be rounded up to be displayed at 1188mV. If you set a voltage non multiple of 12.5mV then for example, 1190mV, it will round it to the nearest valid step, being 1187.5mV. UV_uV_table is there for finer grained control but no app suports that yet.
Perseus alpha3 (4/06):
Mali: disable state tracking
Mali: GPU frequency, scaling and voltage control
Governor pegasusq: make up_threshold_at_min_freq and freq_for_responsiveness configurable values. This is the reason the Galaxy S3 is so smooth, it has super aggressive scaling values for the governor until default 500MHz.
Enabled 1500MHz per defconfig and added voltage values to ASV table for it
Added UV_uV_table for voltage control on the CPU; this is not compatible for any programm which supports undervolting right now, we need UV_mV_table for that and since we have 12.5mV steps being fed to Vdd it's not compatible for now.
Boot partitions are made visible.
Knowledge base
I'm going over time to update this post with some informations. It may be unsorted, unfinished or un-editorialized for the time being.
2) Hardware
The Galaxy Note 2 will be coming out with a new 4412 versioned Rev 2.0, where as the one currently in the S3 is versioned Rev 1.1. The new chip will be launched at 1.6GHz default clock. What is interesting is that they have increased the base clock from 800MHz to 880MHz, most of the SoC internals feed off this clock, meaning that we're going to have 10% clock boost in the internal bus and memory speeds.
Now as a side note: One thing that I haven't understood from the press releases back in May, is that there were this "internal 128bit bus" mentioned, with some idiotic websites taking that tidbit and claiming the chip was a 128bit architecture. Whatever. Anyway, the reason for this is that the way the Samsung SoCs internally function: they are separated in a "left bus" and a "right bus". The left bus is connected to the memory controllers and is also just called the MIF/Memory Interface. The right bus is called the "internal bus" and is connected to the ARM cores and everything else. The biggest difference here between the 4412 and the previous Samsung iterations was that both these were running at the same clock. In the 4412 the internal bus is running at half the memory interface bus, this corresponds to the increase to 128bit in the internal bus.
Now I got curious due to all this talk about the A6 and this tidbit:
"K3PE7E700F-XGC2" the last two characters refer to the clock speed. The iPhone 4S was [under]clocked at 800 Mhz. "K3PE4E400B-XGC1" was the A5's part number. E4 refers to 2 Gb LPDDR2 die and because A5 features a dual-channel LPDDR2 memory with two 32-bit die. 2 GB x 2 = 512 mb of RAM. C1 was the clock speed which was 2.5ns which indicates a 400MHz clock frequency. Two channels result in the A5 clock speed of 800MHz. So the A6 has C2 which is 1.9ns which indicates a 533 MHz clock frequency. 533 x 2 is ~1066 GHz.
Click to expand...
Click to collapse
Both the A6 and 4412 use the same memory, only difference being what seems to be a revision serial character. I was talking a few months ago how the 4412 showed a good 30% bandwidth improvement over the 4210, and credited this to it running 1066mbps memory instead of 800mbps; but in reality that is not the case.
I went over the source code of the busfrequency driver in the S3, and found that actually there is an entry for the internal frequency to run at 266MHz (128bit), but that entry is disabled in the driver; because the memory interfaces don't exceed 400MHz. The bus speed is defined in (MIF/INT) pairs and top speed available is 400200 (400MHz memory, 200 internal). Well this is interesting we can overclock our device's memory then if there's headroom! Well that idea quickly faded as I found that the C2C (Chip-to-chip) interface to the memory isn't capable of being clocked to 533MHz because simply the C2C clock divider register simply doesn't allow a divider value needed for that frequency, only being able to run 400MHz(and lower) and 800MHz. Basically we can't use the fast memory because it seems the clock dividers don't allow it. Anyway, coincidentally the i9305 sources were released two days ago and it included all the Note 2 sources and so on, so what Samsung did was simply increase the MPLL base clock from 800 to 880MHz, actually increasing the frequency of a load of things like the camera interface and who knows what at the same time.
What this also means is that Samsung increased effective bandwidth by 30% without increasing the memory speed. This indicates much improved memory controllers, and also why it easily beats the Tegra 3 and others in memory benchmarks.
Another new addition to the REV 2.0 chip is that we'll be running 533MHz for the Mali clock by default. We were already experimenting with this on the S3 and pretty much made the GPU run up to 700MHz, of course, it gets quite warm and battery hungry, but it's neat nonetheless.
3) Reserved memory spaces
There is the current reserved memory space breakdown, with red as Perseus changes over stock:
#Secure spaces on fixed memory addresses
Front-camera firmware & heap: fimc0: fmic1 =
0x65800000 - 0x66700000 => 15360K (0xF00000) => 14336K
Multi function codec B memory space: mfc-normal =
0x64000000 - 0x64400000 => 4096K
ION device memory allocator reserved space: ion =
0x5F200000 - 0x63800000 => 71680K (0x4600000) => 48128K
Multi function codec device reserved space: device_mfc =
0x5C800000 - 0x5CA80000 => 2560K (0x280000)
Multi function codec A memory space (Virtually contiguous to MFC, practically has a physical memory hole): mfc-secure =
0x5C100000 - 0x5C800000 => 7168K (0x700000)
0x5F000000 - 0x5F200000 => 2048K (0x200000)
Bootloader: sectbl =
0x5C000000 - 0x5C100000 => 1024K (0x100000)
# non secure
Camera imaging subsystem: fimc_is => 12080K (0xBCC000) => 10240K
Display interface and frame buffer: fimd => 8192K (0x800000)
Main-camera firmware & heap: fimc0 => 62464K (0x3D00000)
Audio buffer: srp => 1024K (0x100000)
Good start dude, i will release my kernel in 2 days max too, just need to finish a few things and it's done
Sent from my Desire HD using Tapatalk 2
simone201 said:
Good start dude, i will release my kernel in 2 days max too, just need to finish a few things and it's done
Sent from my Desire HD using Tapatalk 2
Click to expand...
Click to collapse
Desire HD? Did you already get rid of your S2? Thanks. Do you have your device or also waiting for the blue one?
AndreiLux said:
Desire HD? Did you already get rid of your S2? Thanks. Do you have your device or also waiting for the blue one?
Click to expand...
Click to collapse
Haha yeah i sold it to buy a GS3, i ordered the white one from amazon.it but it is taking ages -.-"
BTW, look at my repo, i have done some great new mods if someone wants to use other govs than pegasusq (that is way better but you know, it's always good to have a choice)
Sent from my Desire HD using Tapatalk 2
Nice AndreiFlux let's test
Gesendet von meinem GT-I9300
simone201 said:
BTW, look at my repo, i have done some great new mods if someone wants to use other govs than pegasusq (that is way better but you know, it's always good to have a choice)
Click to expand...
Click to collapse
Great work. Personally I'm not going to allow anything other than Pegasusq though, I just don't see the point. The users can use your kernel if they want choice
AndreiLux said:
Great work. Personally I'm not going to allow anything other than Pegasusq though, I just don't see the point. The users can use your kernel if they want choice
Click to expand...
Click to collapse
Yeah you're right, that's why i will stay with pegasusq by default
My mods are good to use the cores as you want, like it was with Tegrak's 2nd Core
Sent from my Desire HD using Tapatalk 2
Hi
is a bootanimation possible with this kernel or is it in a future version planed?
Bootanimations on the S3 are supposedly in a proprietary format now, so we'll have to see about it. As said, for now it's baby steps as long as I'm not able to molest the flash counter on the device myself.
Wifi is not working on this Kernel
Kevinkuensken said:
Wifi is not working on this Kernel
Click to expand...
Click to collapse
Yes, me too...
+1
Same issue with wifi...
Kevinkuensken said:
Wifi is not working on this Kernel
Click to expand...
Click to collapse
I guess it boots well then! Reuploaded a new version for Wifi, please test if you want to.
AndreiLux said:
I guess it boots well then! Reuploaded a new version for Wifi, please test if you want to.
Click to expand...
Click to collapse
Strange, modules not loaded?
For me it worked perfectly from first build, using fully stock ramdisk
Sent from my Desire HD using Tapatalk 2
AndreiLux said:
I guess it boots well then! Reuploaded a new version for Wifi, please test if you want to.
Click to expand...
Click to collapse
Still no wifi with Alpha3.1
Mopral said:
Still no wifi with Alpha3.1
Click to expand...
Click to collapse
Same here
simone201 said:
Strange, modules not loaded?
For me it worked perfectly from first build, using fully stock ramdisk
Sent from my Desire HD using Tapatalk 2
Click to expand...
Click to collapse
Hmmm. I'm reverting to fully untouched ramdisk now, alpha3.2 uploaded.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This only works on Gingerbread, not anything else. We are still working on finding alternative tweaks for ICS and JBThis is a MOD to boost the performance of the Adreno 205 GPU in the Xperia Play. (This mod should also work on other Adreno devices (Adreno 205+) and whilst some people have had some success I cannot confirm which devices other than the Play it works with)
This mod is a joint collaboration/venture of me and CosmicDan. However, as of version 0.2 CosmicDan has unfortunately left the Xperia 2011 range for better things. I wish him every success in the future.
CosmicDan was able to find a variant of the 'adreno_config.txt' file that contains settings that should work on our device. Since finding this we have found numerous combinations of settings that increase the performance of our chips. See below.
What does it do?
The configuration file consists of multiple options, each which do their very own unique 'tweaking' to the way the GPU performs. One of the most notable options we are using is 'triJuice', an explanation of which is below:
If our phones were to have their own driver application, what this would be doing is essentially moving the 'Quality/Performance' slider towards 'Performance'. This tells the GPU to concentrate on 'Performance' rather than 'Quality'.
See CosmicDan's explanation here:
It's common graphics stuff and the same for PC's, we have told the GPU to put a focus on performance instead of quality. But the quality is not sacrificed much, it's barely noticeable. Maybe some games will look not so well, you'll have to test and see.
It's like we've lowered effect and texture detail on a system-wide level, allowing the CPU and GPU to give more time to work on geometry and frame updates and such. Useful because many games don't have settings for graphics quality.
Click to expand...
Click to collapse
Another notable option is 'forceAutoTextureCompression'. This saves RAM and makes texture rendering faster, but the actual loading of the game might be a tiny bit slower - however once it's loaded it will have faster rendering.
A list of possible settings for this configuration file are below (For detailed descriptions please see attached)
Post 3 lists which settings tend to increase or reduce performance, I will not give instructions on how to modify this however if you to intend on making your own config file please use Post 3 as a guide.
Code:
; Performance Analysis
performance=normal
disableExtraSwapBlit=0
ignoreGLFlush=0
; Binning
binning=hw
forceGuardband=0
guardbandValue=0
forceGmemSize=0
gmemSize=0
veboSetting=0
veboSetting=0
numBins_weight=80
numGroups_weight=20
; Logging
log.resolves=0
log.pm4=0
log.pm4mem=0
log.shaders=0
log.sc_dev=0
log.sc_dev_shader_name=sc_dev_dump.txt
log.cffdump=0
log.cffdump_with_ifh=0
log.cffdump_no_memzero=0
log.dumpx=0
log.primitives=0
; Debugging
waitForIdleAfterDraw=0
waitForIdleOnSubmit=0
disableSwapTsIdle=0
clockGating=off
useSafeMode=0
redirectDebugMessages=0
forceChipId=Default
; Primitive Conversion.
convertTristrips=default
convertTrifans=default
convertLineloops=default
shader_sub.write=0
shader_sub.read=0
shader_sub.trivialfs=0
; Features and Performance
facenessCulling=default
vboDataAlignment=natural
enableOptimizedTextureUpdates=1
enableOptimizedVboUpdates=1
forceAutoTextureCompression=1
triJuice=1
enableInlineConstantUpdates=1
enableMemoryPool=1
enableFastClears=1
ditherSafeFastClears=0
shadowGmemInAppBuffers=1
textureTiling=0
preserveZStencilOnSwap=0
allowDepthExport=0
untileDynamicTextures=1
fullSurfaceDynamicUpdatePath=1
useGpuTilingHints=1
; MultiSampling Antialiasing (MSAA)
MSAASmoothing=Normal
MSAABufferAllocation=never
forceMSAAMode=0
MSAAMode=0
VAESEnable=0
VAESGenericError=0
VAESFailNth=0
VAESDoNotFailFirstN=0
VAESRandomSeed=0
VAESFailPercent=0
; 2D Settings
2D.HwBlt=1
2D.eglSwapMode=noidle
2D.forceEglSwapInterval=0
2D.eglSwapInterval=0
; LEIA Features
leiaEnableLrzWrites=0
leiaEnableLrzExpansion=0
leiaExportColorForLrzUnresolve=0
leiaEnableFastLrzUnresolves=0
; Oxili settings.
oxiliDisableLazyUpdates=0
oxiliDisableChunkedUpdates=0
oxiliForceShaderDirectUpdates=0
oxiliForceConstantDirectUpdates=0
oxiliForceIstoreCacheMode=1
oxiliForceCstoreSingleBuffer=0
oxiliForceShaderSingleContext=0
oxiliForceSuperthreadMode=1
oxiliForceVsSingleThread=0
oxiliForceFsSingleThread=0
oxiliForceSingleSp=0
oxiliSkipClears=0
oxiliForceSysmemRender=1
; Other settings
FPSCap=60
allowFloatFBOs=1
suppressTimestampInterrupts=0
GPUIdleTimeout=off
GPUIdleTimeoutMsec=0
Please ignore the values of the above settings unless otherwise stated. The majority of these are stock/default values for our device.
Downloads - Official repository
AdrenoBooster v0.7
AdrenoBooster v0.6
AdrenoBooster v0.5 - Quality Edition
AdrenoBooster v0.4.1 - Battery Edition
AdrenoBooster v0.3 - Minimal Edition - This version will give you the best performance - stability ratio. Whilst the other versions may give you better performance but in some rare instances lower quality/artifacts, this version should give you the best of both worlds.
AdrenoBooster v0.1
AdrenoBooster v0.2
Instructions
Download and copy the ZIP to SD Card. Then flash using CWM.
NOTE: Please ensure you reboot your device after the first boot post-installation of the mod or it will not be active.
Requirements
Init.d support
Root
Any Gingerbread ROM
Screenshots
IMPORTANT!! - Please ensure you thank 'CosmicDan' as well for this fantastic mod. A huge portion of the work has been done by him!
(See 5th post if you would like to 'Thank' him)
Troubleshooting
First, give yourself another reboot - Just in case!
If it still doesn't seem to be working for you, check to see if the files have copied to your device. Check the following locations for the following files with any file manager with Root support.
/system/etc/init.d - Filename: 93adreno
/system/etc - Filename: adreno_config.txt
You should also see adreno_config.txt in the following location if the init.d script is working correctly: /data/local/tmp
If this file is not in this location then chances are you do not have init.d support.
Black screen on boot? See here: http://forum.xda-developers.com/showpost.php?p=40013461&postcount=377
Extras
You can assist with the testing of some of these settings by doing the following:
Open a new text file in a standard text editor (Notepad++ or Notepad for Windows)
Choose values from the above post to put into your configuration file. (Use the attached adreno_config.txt file as an indication of what setting does what)
Save this new file as 'adreno_config.txt'
Copy this text file to your phones SD Card.
Open your File Manager on your phone (I use ES File Explorer)
Prepare adreno_config.txt on your SD Card for copying
Navigate to /Data/local/tmp and paste the file there
Reboot.
Please be aware that if you have any cleaner init.d scripts this will NOT work, as when you reboot /data/local/tmp will be deleted.
Devs/Chefs/Tinkerers
If you would like to add this to your ROM please simply drop a short request in this thread or PM.
After which, please ensure proper credit is given.
Current Antutu Highscore
(With the benefits of this mod) - By CrypticRook
Manually Uninstalling the Mod
Navigate to the following locations and remove the files.
/system/etc/init.d - Filename: 93adreno
/system/etc - Filename: adreno_config.txt
/data/local/tmp - Filename: adreno_config.txt
Tested Settings
Untested:
preserveZStencilOnSwap - enabling might improve performance at the increased risk of visual artifacts
Dangerous:
facenessCulling - Turning on causes crash on boot
FPSCap - setting to anything other than 0 (even to 60 or 100) causes unstable 2D rendering
2D.eglSwapMode=interrupt - Causes unstable/looping 2D rendering. Applications fail to initialize.
fullSurfaceDynamicUpdatePath - reduces 3D performance by around 10%.
Performance Boosts:
forceAutoTextureCompression - Turning this on seems to help a LOT with 3D performance. Might increase load times by a a tiny amount.
triJuice - setting it to the max value of 3 increases particle/shader/lighting performance a LOT with a minor loss in quality
forceMSAAMode - enabling this will force no anti-aliasing as long as MSAAMode is left at 0. Could increase performance on some things but make them look very chunky
2D.HwBlt - Enabling this should enhance GPU hardware acceleration in gingerbread. It says default is enabled but I've set it to 1 anyway.
oxiliForceVsSingleThread=1 - Must be enabled with oxiliForceFsSingleThread=1 for performance increase. Prolonged usage has negative impact (Needs more testing).
oxiliForceFsSingleThread=1 - Must be enabled with oxiliForceSingleSp=1 for performance increase. Prolonged usage has negative impact (Needs more testing).
oxiliForceSingleSp=1 - Must be enabled with oxiliForceVsSingleThread=1 for performance increase. Prolonged usage has negative impact (Needs more testing).
clockGating - Turning this on might save power consumption (Currently being tested more to confirm). However there is no performance drop by having this enabled
Seemed to hurt performance: (I did not test these much, could do with more tests one-by-one)
leiaEnableLrzExpansion - enabling might.... do something.
leiaEnableFastLrzUnresolves - enabling might improve performance
oxiliDisableChunkedUpdates - enabling might improve performance
oxiliForceShaderDirectUpdates - enabling might improve performance
oxiliForceConstantDirectUpdates - enabling might improve or reduce performance
oxiliForceShaderSingleContext - enabling might improve performance at cost of quality
oxiliForceSuperthreadMode - enabling might improve performance or reduce it. Probably conflicts with above one.
suppressTimestampInterrupts - enabling might improve or reduce performance
Null/No Difference - These options made no effect on performance from their default settings
shadowGmemInAppBuffers - no effect on performance or quality
Great! Really looking forward to seeing what you can do
Thanks for letting me know you opened a topic
I've been doing some research and here's what ideas I've found so far:
clockGating - Turning this on might save power consumption. Will need to test if it has a performance hit.
facenessCulling - Turning on causes crash on boot
forceAutoTextureCompression - Turning this on MIGHT save RAM and/or MIGHT increase load times/CPU usage.
triJuice - raising this value might increase performance but decrease quality of mipmapping.
shadowGmemInAppBuffers - disabling might improve performance but break some things
preserveZStencilOnSwap - enabling might improve performance at the increased risk of visual artifacts
fullSurfaceDynamicUpdatePath - enabling might improve performance at the increased risk of visual artifacts
forceMSAAMode - enabling this will force no anti-aliasing as long as MSAAMode is left at 0. Could increase performance on some things but make them look very chunky
2D.HwBlt - Enabling this might enhance GPU hardware acceleration in gingerbread. It says default is enabled but I've set it to 1 anyway.
2D.eglSwapMode - changing to interrupt mode might.... do something. LETS TRY IT!
leiaEnableLrzExpansion - enabling might.... do something.
leiaEnableFastLrzUnresolves - enabling might improve performance
oxiliDisableChunkedUpdates - enabling might improve performance
oxiliForceShaderDirectUpdates - enabling might improve performance
oxiliForceConstantDirectUpdates - enabling might improve or reduce performance
oxiliForceShaderSingleContext - enabling might improve performance at cost of quality
oxiliForceSuperthreadMode - enabling might improve performance or reduce it. Probably conflicts with above one.
oxiliForceVsSingleThread - enabling might improve or reduce performance
oxiliForceFsSingleThread - enabling might improve or reduce performance
oxiliForceSingleSp - enabling might improve or reduce performance
FPSCap - setting to 30 or 60 might help with all-round performance and reduce lag spikes. Maybe.
suppressTimestampInterrupts - enabling might improve or reduce performance
Right, that's a lot of things for me to try one by one. If anyone else wants to, go for it. Just remember it could completely break your boot
Re: [WIP] Adreno Configuration Settings [Improved Performance?]
I did lol.. In the adreno thread xD
Ill make it more clear next time.
I've just tried a few things... Managed to make Antutu crash lot. Just finally completed a full benchmark but then the OS died. Going well so far. Cya in about 7 hours!
Edit: it looks like you can copy it to data/local/temp and the settings will apply for next boot. After which it is then removed from the directory. Which for me makes things a bit easier!
Sent from my R800i using xda app-developers app
Oh by the way, copying the config file to /system/lib/egl/ definitely does nothing. I tested by setting FPS cap to 5, no effect. File needs to be at /data/local/tmp/ - it does *not* get wiped on reboot so its OK.
EDIT: THe file isn't removed from /data/local/tmp/ for me =\ maybe you have an init.d script that erases it or something.
Re: [WIP] Adreno Configuration Settings [Improved Performance?]
Possibly. Ill check.
Btw, I just managed 13fps on the OpenGL ES2.0 test on Antutu. It was hilarious, so many artifacts... But it passed it!
...Until it died on the SD card test. If you use Antutu I suggest doing custom tests and taking SD out. Or reducing OCs. I think my 1.6ghz may be the problem.
Or perhaps we should use stock clock a to base our tests on?
Edit: seems like almost every setting you try also kills the bootanimation lol
Sent from my R800i using xda app-developers app
Spizzy01 said:
Possibly. Ill check.
Btw, I just managed 13fps on the OpenGL ES2.0 test on Antutu. It was hilarious, so many artifacts... But it passed it!
...Until it died on the SD card test. If you use Antutu I suggest doing custom tests and taking SD out. Or reducing OCs. I think my 1.6ghz may be the problem.
Or perhaps we should use stock clock a to base our tests on?
Edit: seems like almost every setting you try also kills the bootanimation lol
Sent from my R800i using xda app-developers app
Click to expand...
Click to collapse
I can't get past the 2D/sprite test in Antutu (the little Androids) it freezes at the end lol. Boot animation was always OK for me....
Yeah, using a stock clock would be a good idea. But I'm on 1.4 ghz anyway because that's what I've always used and always been stable on.
EDIT: I think setting FPSCap to 60 was the reason for Antutu freezing on 2d test.
EDIT2: You are using LuPuS GB kernel right? Because Turbo Kernel has backported KGSL drivers, so that's probably why we not only have different performance scores but may have different results with these configs.
---------- Post added at 01:24 PM ---------- Previous post was at 01:13 PM ----------
DUDE! New Gingerbread record!
/data/local/tmp/adreno_config.txt:
Code:
facenessCulling=off
forceAutoTextureCompression=1
triJuice=3
2D.HwBlt=1
CosmicDan said:
I can't get past the 2D/sprite test in Antutu (the little Androids) it freezes at the end lol. Boot animation was always OK for me....
Yeah, using a stock clock would be a good idea. But I'm on 1.4 ghz anyway because that's what I've always used and always been stable on.
EDIT: I think setting FPSCap to 60 was the reason for Antutu freezing on 2d test.
EDIT2: You are using LuPuS GB kernel right? Because Turbo Kernel has backported KGSL drivers, so that's probably why we not only have different performance scores but may have different results with these configs.
---------- Post added at 01:24 PM ---------- Previous post was at 01:13 PM ----------
DUDE! New Gingerbread record!
/data/local/tmp/adreno_config.txt:
Code:
facenessCulling=off
forceAutoTextureCompression=1
triJuice=3
2D.HwBlt=1
Click to expand...
Click to collapse
OMFG! LEGEND!
Gonna test on mine and report back ASAP. Gimme 10 - 20 mins, depending on when I can get a free sec @ work. Lol. xD
Edit: Unable to replicate your score at the moment. Getting stock scores, most likely something to do with those pesky init.d scripts. Deleting now and will report back shortly
In the next turbo kernel release I'll make the kernel do a symlink from /data/local/tmp/adreno_config.txt to /system/etc/adreno_config.txt (it will be linked before init starts so will apply straight away), that way we can include modified config with ROM's.
You could just make an init.d script do the same thing, but then the ROM will need to be rebooted again (because adreno driver is already loaded).
CosmicDan said:
In the next turbo kernel release I'll make the kernel do a symlink from /data/local/tmp/adreno_config.txt to /system/etc/adreno_config.txt (it will be linked before init starts so will apply straight away), that way we can include modified config with ROM's.
You could just make an init.d script do the same thing, but then the ROM will need to be rebooted again (because adreno driver is already loaded).
Click to expand...
Click to collapse
I think I'll include an init.d script with my ROM, so that in the event someone isn't using your Kernel it will still work as intended.
...At least, after a reboot.
Doing Antutu now btw, ITS CRAZY FAST OMG. About to give you results. UNO MOMENTO!
OMFG!
This actually brought a tear to my eye... Lmfao... XD
Spizzy01 said:
I think I'll include an init.d script with my ROM, so that in the event someone isn't using your Kernel it will still work as intended.
...At least, after a reboot.
Doing Antutu now btw, ITS CRAZY FAST OMG. About to give you results. UNO MOMENTO!
Click to expand...
Click to collapse
Yeah I realized that too, already done it for Turbo UI Classic (which is uploading now). This should work:
/system/etc/init.d/93adreno:
Code:
#!/system/bin/sh
#
if [ ! -h /data/local/tmp/adreno_config.txt ] then
ln -s /system/etc/adreno_config.txt /data/local/tmp/adreno_config.txt
fi
EDIT:Woohoo! Play broke the 7000 mark
Now I wonder how Jellybean on Turbo Kernel performs.... maybe closer to 8000 lol! And the visual quality of the orc fight 3D test looked OK for you yeah?
CosmicDan said:
Yeah I realized that too, already done it for Turbo UI Classic (which is uploading now). This should work:
/system/etc/init.d/93adreno:
Code:
#!/system/bin/sh
#
if [ ! -h /data/local/tmp/adreno_config.txt ] then
ln -s /system/etc/adreno_config.txt /data/local/tmp/adreno_config.txt
fi
Will be good to know if the results on LuPuS GB kernel are worse, better or the same with this config.
Click to expand...
Click to collapse
My test was done on LuPuS GB.
Sorry - I moved back from your Kernel last night. =x
Thank's for the script. I'll add it to v0.5 Aurora now. xD
Edit: Agreed. JellyBean should have crazy scores... Right, I'm gonna test a few of the other configs. From that list you've done, can you 'tick' off which you have already checked please? Just so I can continue where you left off at.
Orc fight looked perfectly fine. If it were a HD movie I'd say it had a low bit-rate, but it's not... So I have no idea what to call it, but it does look ever so slightly more grainy. But this is barely noticeable at all.
I looked in /data/local/tmp/ and there was no adreno_config.txt I'm using joka wild any ideas did I have to do something before hand using LuPuS v6 480p I'm very interested because I use this a a gaming device as I have a nexus 4
Spizzy01 said:
My test was done on LuPuS GB.
Sorry - I moved back from your Kernel last night. =x
Thank's for the script. I'll add it to v0.5 Aurora now. xD
Edit: Agreed. JellyBean should have crazy scores... Right, I'm gonna test a few of the other configs. From that list you've done, can you 'tick' off which you have already checked please? Just so I can continue where you left off at.
Click to expand...
Click to collapse
I edited my last post since you uploaded results
That's OK, I'll still win the record by being first to test Turbo UI (JB) score lolz
EDIT: OK, I'll edit that list.
extremetempz said:
I looked in /data/local/tmp/ and there was no adreno_config.txt I'm using joka wild any ideas did I have to do something before hand using LuPuS v6 480p I'm very interested because I use this a a gaming device as I have a nexus 4
Click to expand...
Click to collapse
You need to move the file there yourself.
See attached.
Move the file to /Data/Local/tmp and reboot. Ensure you have no init.d scripts that clear cache or tmp though, as it will not work.
OK here's what my data is.
Untested:
clockGating - Turning this on might save power consumption. Will need to test if it has a performance hit.
shadowGmemInAppBuffers - disabling might improve performance but break some things
preserveZStencilOnSwap - enabling might improve performance at the increased risk of visual artifacts
fullSurfaceDynamicUpdatePath - enabling might improve performance at the increased risk of visual artifacts
oxiliForceVsSingleThread - enabling might improve or reduce performance
oxiliForceFsSingleThread - enabling might improve or reduce performance
oxiliForceSingleSp - enabling might improve or reduce performance
Dangerous:
facenessCulling - Turning on causes crash on boot
FPSCap - setting to anything other than 0 (even to 60 or 100) causes unstable 2D rendering
Performance Boosts:
forceAutoTextureCompression - Turning this on seems to help a LOT with 3D performance. Might increase load times by a a tiny amount.
triJuice - setting it to the max value of 3 increases particle/shader/lighting performance a LOT with a minor loss in quality
forceMSAAMode - enabling this will force no anti-aliasing as long as MSAAMode is left at 0. Could increase performance on some things but make them look very chunky
2D.HwBlt - Enabling this should enhance GPU hardware acceleration in gingerbread. It says default is enabled but I've set it to 1 anyway.
Seemed to hurt performance: (I did not test these much, could do with more tests one-by-one)
2D.eglSwapMode - changing to interrupt mode might.... do something. LETS TRY IT!
leiaEnableLrzExpansion - enabling might.... do something.
leiaEnableFastLrzUnresolves - enabling might improve performance
oxiliDisableChunkedUpdates - enabling might improve performance
oxiliForceShaderDirectUpdates - enabling might improve performance
oxiliForceConstantDirectUpdates - enabling might improve or reduce performance
oxiliForceShaderSingleContext - enabling might improve performance at cost of quality
oxiliForceSuperthreadMode - enabling might improve performance or reduce it. Probably conflicts with above one.
suppressTimestampInterrupts - enabling might improve or reduce performance
I made a quick Update ZIP to flash the mod/script and updated the first few posts.
You have been fully credited of course in the updater_script
Gonna look into other settings now.
Edit: I'm not sure I like the new Mediafire layout :|
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
-----JellyKernel-----
This is an all-in-one kernel for Jelly Bean.
Keep in mind, that this kernel is made for balanced battery life. And be advised, that phone could end up in a bootloop. Be awared of that.
DOWNLOAD SECTION IS BELOW!!!
OTG:
HTML:
Some notes:
-Stock ramdisk doesn't have appropriate lines for mounting /sys/kernel/debug, which is needed for manipulating OTG implementation on our device.
-You need to enable OTG support in the system itself. There are apps for fixing that, look up in the Play Store.
-It's still could be kind of jerky to get it to work. Feel free to ask about OTG.
Instructions for OTG support:
1. Open up your terminal and first type:
mount -t debugfs nodev /sys/kernel/debug
2. Now it's tricky:
For peripheral mode (it's default mode used when charging and etc):
Type in the terminal:
echo peripheral > /d/otg/mode
For host mode (for connecting USB devices):
echo host > /d/otg/mode
That's the current implementation atm. I'll try to do something easier later.
Features, which should be implemented later:-Gamma control (will implement that later)
-CPU VDD sysfs interface (useless)
-Higher CPU overclock (not possible yet)
Installation:
Flash this zip through CWM and you're good to go.
Please leave me THANKS if you can.
I want to say thanks to:
CrashBandicootX (for amazing kernel banner)
neutrondev (for giving me some opinions)
dazzozo (for fixing OTG)
skyinfo (for awesome commits)
DOWNLOADS:
BE AWARE, THAT DATA COULD GET CORRUPTED!!! ALWAYS MAKE NANDROID BACKUP BEFORE FLASHING MY NEWEST KERNEL BUILDS! I WON'T BE RESPONSIBLE FOR THE DAMAGE YOUR DATA GOT!!!! IT'S HIGHLY RECOMMENDED TO MAKE FULL DATA WIPE AND REFLASH SYSTEM, BECAUSE KERNEL IS ABSOLUTELY DIFFERENT FROM NOW ON!!!
Build 20150517-015 (STABLE)
HTML:
Fixed camera
Some more cpufreq driver updates
Build 20150516-012 (TESTING)
HTML:
Updated fat filesystem drivers, fixed some bugs
CPU usage dropped at idle
Heavy SLUB optimizations and fixes
Build 20150516-006
HTML:
Fixed some bugs regarding CPU access
Much better hotplug functionality (now you can leave mpdecision enabled)
CPU scaling optimizations
ext4 fix (one weird thing: after installing this kernel, startup wizard will appear - turn off wifi and go through all the procedure, otherwise you will be stuck at google login)
Fixes from LG G2 kernel
Build 20150515-001
HTML:
Tons of improvements
KGSL fixes, stability fixes, working scaling governor
Dynamic FSYNC
Made scaling drivers to work more efficiently
Lessened up chances of QDSP5 to crash in low memory situations, improved decoding
Stabilized wakeup/sleep switching
Several quirks for better interconnect between MDP and GPU
TONS of camera fixes, now it should work marginally better, provide better framerate when recording
Improved ZRAM efficiency
Introduced optimized percpu variable access, which improves performance a little bit
added optimized AES and SHA1 routines
Optimized Adreno drivers, reverted back to stock ones
AND TONS MORE OF STUFF!!!!
DOWNLOAD LINK:
https://www.mediafire.com/folder/78e7p85s3fc9p/KERNELS
Link for the source code:
GITHUB:
https://github.com/airidosas252/android_jellykernel_vee7
thanks for you work,i will definitely try this one.
This is definetly awesome news, I'd like to give a link from my rom to this kernel-can't implement it now, but I'd like to make new versions with your kernel, credits given. Great job, thank you!
Good thing I haven't posted this kernel yesterday. You would have gotten into a real mess: networking would stop working after some use of it.
It was a problem related to compilation. I've fixed it now and testing.
I will upload it to you a little bit later today. Sorry for waiting.
Sent from my LG-P710 using XDA Free mobile app
Please add swap support in next version of this kernel
Doing nandroid backup then im gonna test it,thanks. :good:
Ilyazzzz said:
Please add swap support in next version of this kernel
Click to expand...
Click to collapse
It is there.
i tested the kernel a couple of hours,maybe i made something wrong cause the phone was heating and everytime i exit an app i had redraws on the home screen,some apps just close after using them,without the warning of a FC,like testing the kernel with antutu qhen it reaches 80% the app just closes. And it made the phone slower.
When i made the backup restore i lost a few apps none of them are important,i can download them again.
I used no frills cpu with smartassH3 and vr,with the kernel in max OC and min UC values,and i did not touch the gpu frequency,because i dont know hot to do that.
So basically im not saying the kernel its bad,is that maybe i neded to use another app in order to have better perfomance
So,yes i need help or just point me into the right direction so i can search about it.
I've been using modified kernels,since xperia x10,but this its the first time i have these problems.
And thanks again for your work and effort.
As I mentioned in the thread, avoid using 500 MHz GPU clock. This is the most obvious thing, that makes phone unstable. Set it off using Trickster MOD.
Don't know, why mine is rock stable for like 3 days now (there is something wrong with deep sleep, though. I think different toolchain is responsible for such issue).
I even broke into 10000 (10420 points) mark in Antutu, so yeah... Definitely something's wrong on your phone.
With stock kernel my phone was very laggy, always redrawing no matter which launcher, stutter in almost every game (now even Hungry Shark doesn't lag anymore).
Sent from my LG-P710 using XDA Free mobile app
airidosas252 said:
As I mentioned in the thread, avoid using 500 MHz GPU clock. This is the most obvious thing, that makes phone unstable. Set it off using Trickster MOD.
Don't know, why mine is rock stable for like 3 days now (there is something wrong with deep sleep, though. I think different toolchain is responsible for such issue).
I even broke into 10000 (10420 points) mark in Antutu, so yeah... Definitely something's wrong on your phone.
With stock kernel my phone was very laggy, always redrawing no matter which launcher, stutter in almost every game (now even Hungry Shark doesn't lag anymore).
Sent from my LG-P710 using XDA Free mobile app
Click to expand...
Click to collapse
Thanks for the response,but mate,as i mentioned ,i never touched the GPU frequencies.because i was using only no frills cpu in order to use the max oc and the min oc for the cpu.
I will check that app (trickster mod) asap, right now im at the work,also,if you can ,can you tell me your settings please?
And thanks again.
kalel29 said:
Thanks for the response,but mate,as i mentioned ,i never touched the GPU frequencies.because i was using only no frills cpu in order to use the max oc and the min oc for the cpu.
I will check that app (trickster mod) asap, right now im at the work,also,if you can ,can you tell me your settings please?
And thanks again.
Click to expand...
Click to collapse
Regarding GPU frequencies, it's the same deal as the CPU frequencies, although changing it could either improve performance or make it worse more drastically.
There's nothing so special about my settings: Using 1024 Kb of sd cache, sio i/o governor, smartassv2 cpu governor, leaving both cores online all the time (deleted mpdecision binary from /system/bin folder, because it's too poor for keeping optimal on and off switching of second CPU core). From OS side I've deleted every possible LG app (left nearly at AOSP level), disabled logcat (because I don't need such right now), using Class 10 microSD card, because it won't bottleneck the phone too much. So that's about it.
airidosas252 said:
Regarding GPU frequencies, it's the same deal as the CPU frequencies, although changing it could either improve performance or make it worse more drastically.
There's nothing so special about my settings: Using 1024 Kb of sd cache, sio i/o governor, smartassv2 cpu governor, leaving both cores online all the time (deleted mpdecision binary from /system/bin folder, because it's too poor for keeping optimal on and off switching of second CPU core). From OS side I've deleted every possible LG app (left nearly at AOSP level), disabled logcat (because I don't need such right now), using Class 10 microSD card, because it won't bottleneck the phone too much. So that's about it.
Click to expand...
Click to collapse
ok then,thanks i will try the same settings,also i have a 16gb,class 10 microsd card,and deleted all the lg apps that i dont use. :V
thanks for the reply.
Any possibility of USB OTG being implemented anytime soon?
CrashBandicootX said:
Any possibility of USB OTG being implemented anytime soon?
Click to expand...
Click to collapse
I don't know. It's in the same position as it was in Kitkat - drivers are included but it just doesn't work.
I'll try talking to other developers.
RAM
Hello! :cyclops:
Is there any form to optimize the RAM usage? Any application or something? Greenify works?
Im using v2,everything runs better,and its feels smoother,the only thing that i noticed is that i lost data in some apps,had to disable superSU,and Xposed,and open all the apps that requiere root,in order to regain access to the apps that use superSU again,and finally when im using antutu in order to see how is the perfomance it just closes when its about to finish the benchmark,always,besides that minor thing,the kernel its solid,im using no frills cpu with max freq in 1037mhz,min in 245 mhz, sioplus and smartassh3,(im not touching GPU freq),but every time i restart the phone,the values doesnt stay,y have to manually change the governor and scheduler.
Sorry dude,thanks for your effort but i think my phone doesnt like your kernel,i used trickstermod,no frills,set cpu,and the antutu one,and everytime y reboot the phone the kernel has the default settings again,min freq in 245,max freq in 1,036,and it returns also to ondemand and sio.
:/
I made a backup of my kernel,what partition do i need to restore in order to have the old kernel back?????
and again,thanks.
P.S. a friend is using same kernel in his phone,he is using stock firmware,odexed and im using a custom rom,deodexed. And its the same result in both phones.
@kalel29
To restore old kernel in CWN go to advanced restore and choose boot
sasa g said:
@kalel29
To restore old kernel in CWN go to advanced restore and choose boot
Click to expand...
Click to collapse
Yeah, now I'm encountered certain problems and I was testing backported Kitkat kernel for some time now.
That one is miles better than Jellybean's one (it is too buggy, because simply compiling breaks certain things)
Kitkat kernel, at least, puts phone to sleep state properly (now my phone stays cold throughout whole day, if I don't use it at all, while with Jelly Bean's one, it was always warm, sometimes even hot)
And yeah, sorry, who feels, that posted kernel causes some problems. It is addressed now and fixed.
I'm not an expert in C code, so some specific programming issues are unsolvable for me.
And the feedback is always welcome for me.
TruWhite MOD for Overload Kernel by RandomDelta
I have put together my settings for extracting the best performance with minimal effect on battery life from our Le eco Le 2. I have calibrated the display to true paper white colors and increased saturation to emulate AMOLED displays. Some of you may not like that so you can turn down the color saturation. While changing Voltage settings, please note that not all processors are built the same and yours might not be able to withstand the overclock. If for some reason there are random freezes, Just lower the voltage by 5mv after rebooting. The color profile has been extracted from Le eco vivid color mode EUI 5.9 with boosted color saturation . Not all displays are created equal so the color profile may not be perfect for you. Just adjust RGB by ±5 to get what works best for you. Word of caution, while playing games the phone can get pretty warm. If it concerns you, lower the throttle temperature and Temperature limit under thermal at the cost of some performance. Screen on time is 8 hrs at 50% brightness and 6 hrs at 100% brightness. I recommend 90% for optimum usage. Download the attached zip and adjust settings as in the pictures. Performance Is up by 20% from stock settings and battery usage is 5%less than stock settings. Performance test screenshot is also attached.
Hope you like it . Do comment on how you like it
Suggestions and Requests are welcome.
XDA DevDB Information
TruWhite MOD for Overload Kernel by RandomDelta, Device Specific for the LeEco Le 2 (x52X)
Credits
renjian- for making Overload Kernel
RandomDelta - For Custom Settings and optimizations.
If you don't have Overload Kernel, you can download your preferred version from the link given below
https://androidfilehost.com/?w=files&flid=283143
Instructions
1. Download and flash preferred version of Overload Kernel in Twrp
2. Install Kernel Adiutor and give it Root privileges
3. Download and extract image files from the zip file for corresponding Overload Kernel Version in this post.
4. Compare settings in screenshot images in zip to the settings in Kernel Adiutor and set them to values mentioned in the screen shots. Set them to be applied on Boot. Wait for a few seconds and the new settings will have applied .
Notes:
1. Distribution of TruWhite Mod files directly is not allowed. You are requested to drop a link to this page on the thread you wish to.
2. This is not a flashable zip
3. .json files will be made available on request. Using the .Json file you can import it in kernel Adiutor (donate version),set that to apply on boot and hence apply the customizations in a single click rather than having to fiddle with various settings.
Donation
If you like my work, you can donate me a cup of coffee.
UPI: [email protected]
Changelog
v1.0
1.Smoother I/O performance than stock
2.Increased CPU and GPU performance than stock
3. Fine tuned color profile for a more color accurate vibrant display leading to a more enjoyable media playback experience and Better visibility of small targets in competitive games.
4.Tuned CPU voltages to further increase performance with minimal effect on battery
5. Thermals tuned for delivering maximum performance without thermal throttling .
6. Optimized Memory manager for multi-tasking
7. LKT is not recommended
8. Optimized only for Overload Kernel v4.14
v1.1
1. Increased I/O performance
2.Changed screen color calibration to reduce eye strain
3.Now compatible with LKT
4.Optimized for Overload Kernel v4.14 and v4.15
v1.2
1. Optimized for Overload Kernel v4.19
2. Optimized battery life further.
3. LKT balanced or battery mode suggested as add on.
4.Reduced I/O lag
5. Removed Performance test screenshot
6.Also applicable to Overload Kernel v4.17, v4.18 and v4.20
v1.3
1. Optimized for Overload Kernel v4.21
2. Improved Standby time
3. Improved peak performance by upto 7%
4. Changed screen color calibration to fix oversaturated yellows
5. I/O operations are now less battery intensive
6. Improved Network Performance for faster downloads
7. Optimized thermal performance further
8. Also applicable to Overload Kernel v4.22
9. Color Profile and Thermal calibration is no longer optimised on devices running June 2019 patch or newer due to updated libs.
v1.4
1. Fixed Color Profile and Thermal profile for optimum performance.
2.Tuned Kcal to be slightly warm to reduce eye fatigue.
3. Color Calibration based on Redmi Note 7 Pro Increased Contrast (Cool) display profile.
4.Improved Standby time significantly.
5. Reduced idle battery drain
6. Increased GPU performance while gaming.
7.Tuned Cpu Voltages to prioritise performance under heavy load and battery under light load.
8. Unable to fix I/O lag. Still looking into how to solve it. Help is appreciated. Virtual Memory needs to be tweaked further.
9. Optimized for Overload Kernel v4.23
This project has been abandoned as Overload Kernel is no longer being updated
Version information
Status : Stable
Current Stable Version : v1.4
Latest Version :v1.4
Final Version :v1.4
Created 25-01-2019
Last Updated 28-07-2019
Reserved
Can this for 4.15?
How about gaming?
Its good or nah?
Restian Rony said:
Can this for 4.15?
How about gaming?
Its good or nah?
Click to expand...
Click to collapse
Every Version of kernel is different from each other and features pop up and disappear with updates. So certain customizations mentioned in this guide may not be available in a different kernel version. Also, optimum values tend to differ from kernel version to version. So yeah, it'll work in v4.15 but you might not get the best results.
It's good for gaming coz you get a 20% performance boost over stock. You can improve performance further by changing CPU and GPU governers to Performance, increasing minimum CPU and GPU speed, increasing minimum number of big cores online and increasing the temperature limits but it will adversely affect your thermals and battery life.
RandomDelta said:
Every Version of kernel is different from each other and features pop up and disappear with updates. So certain customizations mentioned in this guide may not be available in a different kernel version. Also, optimum values tend to differ from kernel version to version. So yeah, it'll work in v4.15 but you might not get the best results.
It's good for gaming coz you get a 20% performance boost over stock. You can improve performance further by changing CPU and GPU governers to Performance, increasing minimum CPU mad GPU speed, increasing minimum number of big cores online and increasing the temperature limits but it will adversely affect your thermals and battery life.
Click to expand...
Click to collapse
Wow thanks mate
Love u ?
Update
V1.1 now available.
Will release performance biased mod shortly. Hope you all like it
I can not find the core control setting screen (the one attached)
Why not share the .json profile file directly?
danyel980 said:
I can not find the core control setting screen (the one attached)
Why not share the .json profile file directly?
Click to expand...
Click to collapse
Are you on Overload kernel v4.14. Please ensure that you are. Even if I share the Json file, that setting won't be applied because that setting doesn't exist for the kernel you are on. So it's pointless. Plus to apply the Json file, you need to have the pro version of Kernel Adiutor , which most of us don't. If you want the Json file, it's linked below.
It's the v1.1 Balanced profile
RandomDelta said:
Are you on Overload kernel v4.14. Please ensure that you are. Even if I share the Json file, that setting won't be applied because that setting doesn't exist for the kernel you are on. So it's pointless. Plus to apply the Json file, you need to have the pro version of Kernel Adiutor , which most of us don't. If you want the Json file, it's linked below.
It's the v1.1 Balanced profile
Click to expand...
Click to collapse
yes, I'm overloaded 4.14 but I can not find the screen in question.
thanks for the .json file, even if you say in effect it does not make much sense unless you can apply the whole configuration. I would like to understand why I do not find the setting, however
danyel980 said:
yes, I'm overloaded 4.14 but I can not find the screen in question.
thanks for the .json file, even if you say in effect it does not make much sense unless you can apply the whole configuration. I would like to understand why I do not find the setting, however
Click to expand...
Click to collapse
Maybe there was some error during the flashing process. You should redownload the kernel And flash it again. It should solve the issue.
Custom settings for Overload Kernel v4.19 has been released
Settings for v4.20 are the same as for v4.19. So I'm not reposting.
Settings for v4.21 will be released soon.
Thanks for the great work
Waiting for v21 TIA
TruWhite MOD v1.3 for overload kernel v4.21 has been released!
I will not be releasing performance biased mod because in my opinion the battery trade off associated is not worth the tiny performance gain.
RandomDelta said:
TruWhite MOD v1.3 for overload kernel v4.21 has been released!
I will not be releasing performance biased mod because in my opinion the battery trade off associated is not worth the tiny performance gain.
Click to expand...
Click to collapse
After downloading and flashing Ol 4.21, it is showing 4.20 of 17th Feb..... What to do?
MpS005 said:
After downloading and flashing Ol 4.21, it is showing 4.20 of 17th Feb..... What to do?
Click to expand...
Click to collapse
Don't worry . You are on v4.21. Renjian forgot to update the build release key description.
RandomDelta said:
Don't worry . You are on v4.21. Renjian forgot to update the build release key description.
Click to expand...
Click to collapse
but my last option for max frequencies for big cpu is 1478mhz. There's no 1800mhz or around it
MpS005 said:
but my last option for max frequencies for big cpu is 1478mhz. There's no 1800mhz or around it
Click to expand...
Click to collapse
It's for little CPU. You might be confused. Little CPU max out at 1478mhz in v4.21. Send screenshots . I might be able to help
RandomDelta said:
It's for little CPU. You might be confused. Little CPU max out at 1478mhz in v4.21. Send screenshots . I might be able to help
Click to expand...
Click to collapse
I sorted out. It was showing wrong info. It was showing 1478mhz in big and 1843mhz in small. LOL. I force stopped app and rebooted phone. Then, it was correct.....Wait for results now:fingers-crossed:
Introduction:
Hi everyone and welcome to another guide. Today I will be teaching you how to get the most out of that Exynos 9820, inside that S10 of yours. We will be focusing on three main things in this guide. Debloat, Mtweaks and DVFS (The ace up our sleeves). So without further ado, lets get right to it.
Requirements:
1. A OneUI ROM, or custom ROM, with Magisk - If the ROM comes pre-debloated, even better, you can skip Step 1.
2. MTweaks - https://github.com/morogoku/MTweaks-KernelAdiutorMOD/releases - Mtweaks is going to be controlling our kernel and helping us get extra power.
3. A root explorer - I use solid explorer, its the easiest and looks the nicest but has a trial date, although any explorer is fine.
Step 1: Debloating:
Now this should come as no surprise, that having a light operating system, will obviously benefit performance. Now I'm not gonna sit here, and type all the apks, permissions etc. that you have to remove. However the three apks that are essential to better gaming performance, are GameLauncher, GameOptimizingService and Gametools. I will explain why in the next section:
1. Gamelauncher: The app in itself isn't that bad, the main problem is its control on the performance of the device. It isn't the main culprit here, but any link that the service has to the kernel needs to be stopped for the future steps.
2. GameOptimizingService: This is the main culprit and the service I am referring to. GOS has this "feature" to control the performance of the device, and whether to focus on performance or focus on battery. After extensive testing, this app does the inverse of what it is supposed to do as it tends to throttle performance, regardless of what setting you place it on and for the steps I'm going to explain later, you will know anything linked to controlling the kernel needs to be killed.
3. GameTools: Once again, not the main culprit, but as I have stated before, it has a link to the throttling service, and unfortunately has to go, along with the other three apks.
The path for the three apks:
system/app/GameOptimizer
system/app/GameOptimizingService
system/priv-app/GameHome
system/priv-app/GameTools_Dream
system/etc/permissions/privapp-permissions-com.samsung.android.game.gamehome.xml
system/etc/permissions/privapp-permissions-com.samsung.android.game.gametools.xml
system/etc/permissions/privapp-permissions-com.samsung.android.game.gos.xml
I know that most people love the organization skills of Game Launcher and the functionality of Game Tools, but all I ask for is a little leap of faith here, when I say they aren't good for gaming performance. Of course you can continue the guide without the removal of these apks, but I cannot guarantee the performance I promised at the start of the guide.
Step 2: Disabling DVFS
The second step on this journey is going to be the disabling the absolutely horrible thermal throttling system on any Samsung device known to man, called DVFS. It is singlehandely the main reason, why your exynos chipset cannot play games at the same framerate as a Snapdragon chipset from two years ago, and is also why AOSP tends to not throttle like OneUI does. Today we will be killing it, and restoring the CPU and GPU performance of your device.
Note: Disabling DVFS will have lots of obvious benefits which will be very noticeable, but does come with its own sets of downsides. Once killed, you have to reboot the device to re-enable DVFS as with DVFS disabled, there is nothing telling the kernel to be conservative and therefore, there will be a slight increase in drain while using apps. All you have to do to fix it, is reboot the device and DVFS re-enables itself.
Note 2: Every time you reboot, you will have to repeat this process as DVFS does re-enable itself, so keep this guide handy, or memorize the steps.
Lets get started. (I will post screenshots of me using solid explorer)
1. Open up your root file explorer, grant Magisk permissions and goto the root folder (or main system directory)
2. Once you are in the root directory, goto the folder called sys
3. Then goto the folder called devices
4. Then goto the folder called platform
5. Now search the word "mali"
6. Press on the first folder you see
7. Now look for three files, dvfs, dvfs_max_lock and dvfs_min_lock
8. Press and hold on the file dvfs and goto its properties
9. Now goto its permissions and disable all its permissions. There should be a single tick mark on any of the permissions.
10. Now save the file and do the same for dvfs_max_lock and dvfs_min_lock
Thats it. You have now disabled the thermal throttling system on your device. Now remember, by doing so, your device won't throttle until its hit the chipset thermal limit (which is a lot higher than DVFS's thermal limits), so don't run the overclock we plan on using unnecessarily (You don't need max performance to scroll through Instagram XD)
Step 3: MTweaks
What is MTweaks? Mtweaks is a kernel manager that was built by @morogoku specifically for exynos based devices. Now with this kernel manager, you now have access to your CPU and most importantly your GPU. When we killed GameLauncher, Gametools and GameOptimizationService, we removed the ability for GOS to throttle the device in advance. When we disabled DVFS, we set the kernel free of the five year old messing with the settings, when things got a bit too intense, and now we have the ability to fully utilize our kernel.
Now after extensive testing, touching the CPU frequencies tends to have the inverse effect unless your underclocking to save power, so we're not going to adjust its frequencies. The GPU is going to be the main area of improvement. Before you go-to play whatever game you want to play, if it is something light, set the minimum frequency to half of the maximum frequency. So if its something light like candy crush, set the GPU's minimum frequency to 325mhz and the GPU Power Policy to Always ON. If you plan on playing something that's going to require a lot more horsepower, like lets say, PUBG Mobile with UHD and all settings maxed out via GFX Tools (Yes I am a madman), put the GPU's minimum frequency at 702mhz and the GPU Power Policy to Always ON, and thats it, your done. You should now be able to outperform or at least match the performance figures given in your Antutu Benchmark. Keep in mind obviously the thermal restrictions, and as a rule of thumb, check Mtweaks once in a while to check your temps. The main temp I've noticed to take an increase is the battery, and keeping it below 45C is optimal while gaming. The GPU and CPU don't need to be monitored.
Disclaimer: I will not be held responsible for any nuclear explosions because you pushed your device too hard by using this guide. Please be responsible and be aware that your phone is a phone, not a gaming PC with a huge fan to cool it off
Conclusion:
I will post a screenrecording of my s10's gameplay of PUBG Mobile on UHD with all settings maxed out on GFX Tools, and screenshots of MTweaks and solid explorer. I hope this guide helped you achieve the gaming performance you desired out of your Exynos based Galaxy S10. Hit the thanks button if I helped you
Well, it seems to do the job very well. No lags for now, im playing full graphics with wqhd+ display settings (like never before, it really fly). Cons: a little more battery consumption and more heat (but no so much really). If this was an S7 it will burn your fingers for sure. So, i think this mod on S10 can't damage the phone, only the battery life can be shortened on a large-term if the use is heavy. But... is one thing on another.. i prefer playing good. Thank you for the guide.
Skulldron said:
Introduction:
Step 1: Debloating:
Now this should come as no surprise, that having a light operating system, will obviously benefit performance. Now I'm not gonna sit here, and type all the apks, permissions etc. that you have to remove. However the three apks that are essential to better gaming performance, are GameLauncher, GameOptimizingService and Gametools. I will explain why in the next section:
1. Gamelauncher: The app in itself isn't that bad, the main problem is its control on the performance of the device. It isn't the main culprit here, but any link that the service has to the kernel needs to be stopped for the future steps.
2. GameOptimizingService: This is the main culprit and the service I am referring to. GOS has this "feature" to control the performance of the device, and whether to focus on performance or focus on battery. After extensive testing, this app does the inverse of what it is supposed to do as it tends to throttle performance, regardless of what setting you place it on and for the steps I'm going to explain later, you will know anything linked to controlling the kernel needs to be killed.
3. GameTools: Once again, not the main culprit, but as I have stated before, it has a link to the throttling service, and unfortunately has to go, along with the other three apks.
The path for the three apks:
system/app/GameOptimizer
system/app/GameOptimizingService
system/priv-app/GameHome
system/priv-app/GameTools_Dream
system/etc/permissions/privapp-permissions-com.samsung.android.game.gamehome.xml
system/etc/permissions/privapp-permissions-com.samsung.android.game.gametools.xml
system/etc/permissions/privapp-permissions-com.samsung.android.game.gos.xml
Click to expand...
Click to collapse
If only disable the packed with some app It's same?
xaloundros said:
If only disable the packed with some app It's same?
Click to expand...
Click to collapse
While I haven't tested this myself, in theory it should work, however further testing could be required