[KERNEL][FORK]Radioactive Kernel V2.2.5 [2021.07.28][OOS/CUSTOM ROMS][UNIFIED OP8/OP8Pro/OP8T] 295-920Mhz GPU + WL Blocked + Adreno Boost

Search This thread

mslezak

Senior Member
Dec 12, 2016
410
403
Houston
Google Pixel 2
OnePlus 8T
Sorry guys for waiting on the next release from the original dev of RadioActive; I tried to do an auto-merge from GitHub but there are too many conflicts for me to resolve in the little time I have. I usually (to avoid messing anything up) completely move the prior repo to another one, clone the latest version, then apply my commits on top of that. But that takes a bit of time to do. And I'm working 80hr+ weeks ATM so don't expect an updated fork for a little bit... Hard to fit in family and work and kernels etc. when you barely have enough time in the day to do anything but work / sleep / eat. But it will come. Probably between all the coding I do at work...
 

krkhaha

Senior Member
Dec 28, 2013
652
129
Kraków
OnePlus 8
Sorry guys for waiting on the next release from the original dev of RadioActive; I tried to do an auto-merge from GitHub but there are too many conflicts for me to resolve in the little time I have. I usually (to avoid messing anything up) completely move the prior repo to another one, clone the latest version, then apply my commits on top of that. But that takes a bit of time to do. And I'm working 80hr+ weeks ATM so don't expect an updated fork for a little bit... Hard to fit in family and work and kernels etc. when you barely have enough time in the day to do anything but work / sleep / eat. But it will come. Probably between all the coding I do at work...
It was asking if you have a plan to update. We don't expect you did it now😁
 
  • Like
Reactions: trongthanh

mslezak

Senior Member
Dec 12, 2016
410
403
Houston
Google Pixel 2
OnePlus 8T
Yeah the new releases of the Radioactive fork have some things I'm not that happy about. But they really don't make a whole lot of difference. One is switching from MQ schedulers (the norm on this higher Linux version) to SQ ones. Are the speed differences that significant? Not really, but I view MQ schedulers for tasks as ahead of SQ (sign0al queue) to be the "old world" version of them. As I mentioned at some point, this change (addition / reversion) caused many conflicts and a simple GitHub merge isn't possible. I tend to like my MQ schedulers, as they are intended for high speed SSD hardware. Which the Op8T has already. To me, introducing old schedulers is not ideal. The I/O speed you likely would not even notice in normal activities, but it exists. There are some improvements he's made (even in his unpublished repo, latest commits) that would add extra battery life, but fixing all the commits that don't automerge is a pain. So if I do create a new version, well, it will be based on a clean repo download to another branch. But as mentioned prior, I really don't have the time right now. Sorry if that disappoints some people, but I have a full time job that doesn't give me any room to keep up open source RadioActive fork builds with my tweaks added. At some point, maybe over the holidays, I'll make another build, when my time is less demanding at my actual job. This is just a hobby, i.e. build for fun, as I don't get any money for builds.
 

cubeplayer1

Member
Dec 13, 2017
40
22
Google Pixel 3
OnePlus 8 Pro
Yeah the new releases of the Radioactive fork have some things I'm not that happy about. But they really don't make a whole lot of difference. One is switching from MQ schedulers (the norm on this higher Linux version) to SQ ones. Are the speed differences that significant? Not really, but I view MQ schedulers for tasks as ahead of SQ (sign0al queue) to be the "old world" version of them. As I mentioned at some point, this change (addition / reversion) caused many conflicts and a simple GitHub merge isn't possible. I tend to like my MQ schedulers, as they are intended for high speed SSD hardware. Which the Op8T has already. To me, introducing old schedulers is not ideal. The I/O speed you likely would not even notice in normal activities, but it exists. There are some improvements he's made (even in his unpublished repo, latest commits) that would add extra battery life, but fixing all the commits that don't automerge is a pain. So if I do create a new version, well, it will be based on a clean repo download to another branch. But as mentioned prior, I really don't have the time right now. Sorry if that disappoints some people, but I have a full time job that doesn't give me any room to keep up open source RadioActive fork builds with my tweaks added. At some point, maybe over the holidays, I'll make another build, when my time is less demanding at my actual job. This is just a hobby, i.e. build for fun, as I don't get any money for builds.
I very much appreciate the update and time you spend on your hobby! Happy Holidays
 

mslezak

Senior Member
Dec 12, 2016
410
403
Houston
Google Pixel 2
OnePlus 8T
Finally got around to building this - the dev changed so much I had to dump everything and start again from his source. Since I can't test custom I won't post it since people said they got crashdumps from something (not sure what). So OOS with all the features of the prior builds is available for download. Note I haven't tested everything out yet, just basic functionality and I really had to hack the living hell out of his code to compile with Proton Clang 12. No, I didn't do it in a proper way, but it works anyhow. Needed to install from the dev channels GCC (I think version 11) and update a whole lot of other things. So it's his last build V2.3.1, it's quite good from using it for a day now.


Sorry, all the old ones are gone. Just wanted to get the right source on the repo and it overwrote everything that was there already. My commit history is horrible because I didn't really expect anyone else to use it but me, but whatever, it's there. If you want to compile it yourself there's a submodule for the scripts/dtc-aosp/dtc/ that needs a bug fix (I couldn't include it because, well, he added it as a submodule). git submodule init; git submodule update; both required before grabbing those. Just Google the error for the fix.
 
Finally got around to building this - the dev changed so much I had to dump everything and start again from his source. Since I can't test custom I won't post it since people said they got crashdumps from something (not sure what). So OOS with all the features of the prior builds is available for download. Note I haven't tested everything out yet, just basic functionality and I really had to hack the living hell out of his code to compile with Proton Clang 12. No, I didn't do it in a proper way, but it works anyhow. Needed to install from the dev channels GCC (I think version 11) and update a whole lot of other things. So it's his last build V2.3.1, it's quite good from using it for a day now.


Sorry, all the old ones are gone. Just wanted to get the right source on the repo and it overwrote everything that was there already. My commit history is horrible because I didn't really expect anyone else to use it but me, but whatever, it's there. If you want to compile it yourself there's a submodule for the scripts/dtc-aosp/dtc/ that needs a bug fix (I couldn't include it because, well, he added it as a submodule). git submodule init; git submodule update; both required before grabbing those. Just Google the error for the fix.
If you need someone to test custom I'd be happy to help.
 

mslezak

Senior Member
Dec 12, 2016
410
403
Houston
Google Pixel 2
OnePlus 8T
If you need someone to test custom I'd be happy to help.
Yeah I didn't even clone the custom fork so it's not even in my repo - probably best sticking to Radioactive and using KonaBess if you want to change GPU frequency clocks (I think he added the same ones except 295 (lowest) and 920 (highest).

In a kernel manager you can try blocking anything I do (WakeLocks) via code although a bit of a pain to add manually - at least you know it will work. Both EXKM and SmartPack will detect Boeffla WL Blocker.


Blocked WakeLocks list:
qcom_rx_wakelock;
998000.qcom,qup_uart;
bluetooth_timer;
hal_bluetooth_lock;
smp2p-sleepstate;
wlan;
wlan_pno_wl;
fastcg_wake_lock;
c440000.qcom,spmi:qcom,[email protected]:qcom,qpnp-smb5;
bq_delt_soc_wake_lock;
alarmtimer

Then you can set the Adreno Boost on boot to low as well and you basically have what I compiled for OOS.

That's all I can suggest at this time, back to work tomorrow...
 

FoxyDrew

Senior Member
Aug 18, 2014
1,226
510
East Taunton
Finally got around to building this - the dev changed so much I had to dump everything and start again from his source. Since I can't test custom I won't post it since people said they got crashdumps from something (not sure what). So OOS with all the features of the prior builds is available for download. Note I haven't tested everything out yet, just basic functionality and I really had to hack the living hell out of his code to compile with Proton Clang 12. No, I didn't do it in a proper way, but it works anyhow. Needed to install from the dev channels GCC (I think version 11) and update a whole lot of other things. So it's his last build V2.3.1, it's quite good from using it for a day now.


Sorry, all the old ones are gone. Just wanted to get the right source on the repo and it overwrote everything that was there already. My commit history is horrible because I didn't really expect anyone else to use it but me, but whatever, it's there. If you want to compile it yourself there's a submodule for the scripts/dtc-aosp/dtc/ that needs a bug fix (I couldn't include it because, well, he added it as a submodule). git submodule init; git submodule update; both required before grabbing those. Just Google the error for the fix.
Dude awesome work, this has been the only kernel I've used since you released it. Battery life is insane.

Any chance you can make a fastboot flashable image for the new version?
 

mortazanabin

Member
Oct 8, 2015
32
6
i am on oos... i selected 920mhz from franco kernel manager but when testing with antutu bechmark gpu speed stuck at 587mhz... can't use 920mhz...
i used perfmon+ for monitor gpu speed...
Screenshot_20220128-205440.jpg

how to fix that....?
 

Top Liked Posts

  • There are no posts matching your filters.
  • 22
    Can I get a link to try this? Tia
    Updated 7/31/2021 rebased on Acuicultor's v2.2.5 rebase (OOS) and rebase_custom (custom ROMs).

    [NOTE: Bug reported - with a Magisk Module I created to fix it. For some strange reason (code looks fine), some systems are setting the default GPU frequency to 920mhz and default power level to 0 (max). I have posted a small Magisk Module that waits 5 seconds then corrects these values (295mhz default and power level 8). It's on the GitHub release page - MOD-GPU-Set-Min-Freq.zip. Just install with Magisk Manager as a module / install from storage after downloading.]

    This is a tweaked version of RadioActive kernel by acuicultor modded for higher performance and lower idle drain. All source commits and releases are on my GitHub fork:


    PLEASE read the Readme as well as the disclaimer. Whenever you flash a custom kernel, you do so at your own risk. I recently rebased on the dev's work (GPU_OC OOS branch, never released) and set the wakelock blocks up myself (lower idle drain, tested over a week with no loss in functionality), dropped the base GPU frequency to 295mhz and raised the top ones (800/920mhz) acuicultor you're an awesome dev, great to have you around! All credits should go to him other than my tweaks.

    I also merged all the same changes into the Custom ROM branch which didn't have GPUOC or AdrenoBoost - several people are using it now but it's marked as a BETA since I am on OOS (latest Global) and can't test it myself. NOTE: many people on the TG channel I posted to have tried it and have had no issues on Op8, Op8 Pro, and Op8T.

    Note if you are one of the rare people who see artifacts in games or benches, the easiest fix is to go into your kernel manager and set the max GPU frequency to 800mhz and apply on boot. Not all 865 Adreno GPUs are created equal. I haven't seen one that couldn't handle 900mhz to date, but enough people have had no issues at 920mhz so that's where I put it.

    Be sure to flash Magisk before installing, then use EX Kernel Manager or FK Kernel Manager to Flash the kernel zip. It has all the same optimizations of RadioActive kernel, just modded for really nice performance and low battery drain. Adreno Boost is set to low on default which makes it react faster as the GPU scales. If you already have Magisk installed, there is no reason to reinstall it - the AnyKernel 3 zip installer will use what's installed already.

    I put one out there you can just flash from: fastboot flash boot 4.19.110.RadioActive-WL-295_UC-920-GPU-2.2.5.img (OOS only) as it saved my a$$ a couple times when flashing or trying to apply an incremental update when rooted (no success, although I posted the incremental update on TG, the payload just won't extract properly to update using fastbootd scripts)... Maybe I'll post it here on XDA and see if anyone can extract the latest Op8T update.

    Also someone sent me a PM about using KonaBess app to change frequencies even more, or change regulators, or change the DDR clock speeds. Yes, it works. Note you probably should only play with that if you have a fastboot image available in case it doesn't boot! I did just upload one for OOS to the repo as I mentioned above. Be warned, you're on your own there.

    Hope you all enjoy!

    - MattOfTheDead / Red Magic 5G MOD kernel (Q) / Xiaomi Mi9 / Mi9T Pro MOD kernels (Pie/Q) / next in line is probably a 2022 device - 888s didn't make the cut
    9
    I posted an updated Radioactive kernel with various mods (GPU UC 295, OC 920, 11 Wakelocks blocked for idle drain, Adreno Boost set to minimum.) Built on request from a few people on TG it's just a "preset" version of Acuicultor's work, built with Proton Clang 12 instead. I did barely anything, just set it up the way I like it, but it's available here for anyone that wants it:


    As I said, I didn't do much so thank the real dev in this thread by supporting him!
    5
    Sorry guys for waiting on the next release from the original dev of RadioActive; I tried to do an auto-merge from GitHub but there are too many conflicts for me to resolve in the little time I have. I usually (to avoid messing anything up) completely move the prior repo to another one, clone the latest version, then apply my commits on top of that. But that takes a bit of time to do. And I'm working 80hr+ weeks ATM so don't expect an updated fork for a little bit... Hard to fit in family and work and kernels etc. when you barely have enough time in the day to do anything but work / sleep / eat. But it will come. Probably between all the coding I do at work...
    5
    Thanks guys for the kind words from those of you that like my kernel. I've been running it all the time and it's never crashed on me. It's still a good habit to reboot your phone every day, or every few days. But I've only tested OOS since I don't run custom ROMs.

    Sorry busy on other projects at the moment, no time to update to the newest release of Radioactive. Of course no one has paid me to do it, and I have an 888 phone now (Redmi K40 Pro Plus 12/256 from China, $600 delivered in 10 days to my house from China directly - PM me if interested, the place to order is 100% Chinese and my Chinese speaking friends can't even figure out how to order there, but somehow, I did thanks to Google Lens and Translate). I still use my Op8T 5G all the time though. It's a great phone.
    5
    Yeah the new releases of the Radioactive fork have some things I'm not that happy about. But they really don't make a whole lot of difference. One is switching from MQ schedulers (the norm on this higher Linux version) to SQ ones. Are the speed differences that significant? Not really, but I view MQ schedulers for tasks as ahead of SQ (sign0al queue) to be the "old world" version of them. As I mentioned at some point, this change (addition / reversion) caused many conflicts and a simple GitHub merge isn't possible. I tend to like my MQ schedulers, as they are intended for high speed SSD hardware. Which the Op8T has already. To me, introducing old schedulers is not ideal. The I/O speed you likely would not even notice in normal activities, but it exists. There are some improvements he's made (even in his unpublished repo, latest commits) that would add extra battery life, but fixing all the commits that don't automerge is a pain. So if I do create a new version, well, it will be based on a clean repo download to another branch. But as mentioned prior, I really don't have the time right now. Sorry if that disappoints some people, but I have a full time job that doesn't give me any room to keep up open source RadioActive fork builds with my tweaks added. At some point, maybe over the holidays, I'll make another build, when my time is less demanding at my actual job. This is just a hobby, i.e. build for fun, as I don't get any money for builds.