So goin full bars, 2 bars, no bars every 3-4 seconds in cm based roms is acurate? Not being smart, new phone just started messing with it and reading forums.
Sent from my ONEPLUS A3000 using Tapatalk
[UNIFIED] Render Kernel [OOS-N-EAS-R2][LOS-N-EAS-R8]
- Thread starter RenderBroken
- Start date
- Status
Sent from my ONEPLUS A3000 using Tapatalk
I can't really give a definitive answer to it. Just stated an opinion which i derived from multiple posts. Tbh i don't have an issue on either, which i mentioned above. If you still disagree, peace.
Well, I've read in various threads in this device that OOS gives a more friendly report of signal readings. The CM signal values are slightly more accurate. From the dB values there's only like a minor, insignificant difference I'd say. But on the status bar, not quite. I am not 100% sure the info is correct, this is based on what I've read from multiple reports. To me it doesn't matter so much really, the call goes, I'm able to speak and hear clearly. Only time i check carefully is during mobile data usage, and for me that also seems to run fine on both OOS or CM based ROMs. cheers
Thanks bro for the info!
Don't agree or disagree, if u read my post im new to this device, just trying to figure it out.I can't really give a definitive answer to it. Just stated an opinion which i derived from multiple posts. Tbh i don't have an issue on either, which i mentioned above. If you still disagree, peace.
Sent from my ONEPLUS A3000 using Tapatalk
Sorry, i thought that was a typo or something. ? my bad. Anyway, I think further discussion on this would go off topic, and I don't want to contribute to doing that at any point. Peace
Not sure what you are referencing? Also with which build are you using? Lastly, what are you measuring app loading times with? I seen that in the interactive thread. Just couldn't find the app ppl are using.
Sent from my ONEPLUS A3000 using XDA-Developers mobile app
That 9 mA current draw of idling is staggering! That was with the latest non-EAS build of yours.
The app i am using is DiscoMark :good:
P.S. It is midnight here
That 9 mA current draw of idling is staggering! That was with the latest non-EAS build of yours.
The app i am using is DiscoMark :good:
P.S. It is midnight here
I really wanna test this kernel as I know you do lots of testing and research and it seems this kernel is a real performer but I just CBA to flash OOS lel.
But I am definitely gonna do it in the near future.
Well, I am kinda waiting for the official n source before releasing for cm and such custom roms. Just have to see.
Sent from my ONEPLUS A3000 using XDA-Developers mobile app
@RenderBroken can I use the kernel with f2fs for /data ?
I have not edited the FSTAB yet to allow it but once done it will support it.
Render Kernel: Release 1
It took 70 Test builds but it is finally here:
Download
Things to note:
First, I will not be building EAS in my builds. EAS requires many Rom side changes to be utilized properly. I may work to do CM Rom builds with EAS but don't have the time at the moment.
I have worked to release a fully featured build that is stable, fast and retains battery. There are many aspects that I have changed or tweaked. See below for the full list of changes. Mains things are, I have brought my source inline with CAF LV.HB.1.3.2 in a few places. built with Linaro GCC 5.3.2, updated WLAN and many more small changes. My goal was not to stray too far but to improve in small places. Thanks to all the other devs out there and their contributions!
Let me know what you guys thinks.
Changelog
It took 70 Test builds but it is finally here:
Download
Things to note:
First, I will not be building EAS in my builds. EAS requires many Rom side changes to be utilized properly. I may work to do CM Rom builds with EAS but don't have the time at the moment.
I have worked to release a fully featured build that is stable, fast and retains battery. There are many aspects that I have changed or tweaked. See below for the full list of changes. Mains things are, I have brought my source inline with CAF LV.HB.1.3.2 in a few places. built with Linaro GCC 5.3.2, updated WLAN and many more small changes. My goal was not to stray too far but to improve in small places. Thanks to all the other devs out there and their contributions!
Let me know what you guys thinks.
Changelog
Any chance that the latest r1 is compatible with open beta 7 marshmallow version !
Not sure, still new to the ins and outs of the OP3. I tack with Stock OOS. So not sure what Open Beta 7 M version has different. Cant hurt to try it out.
If anyone knows, please drop a line. I cannot jump to new roms too often as I need my phone for my 2 jobs.
As far as I can tell everything is working on Open Beta 7. WIFI, SDCard are working properly. I will report back if I have any issues.
Yes sir! Thank you very much for the hard work! Kernel is SMOOTH!
- Status
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
120
for OOS-N, and LOS-N
Code:/* *** Disclaimer * I am not responsible for bricked devices, dead SD cards, thermonuclear war, * or you getting fired because the alarm app failed. Please do some research * if you have any concerns about features included in this KERNEL * before flashing it! YOU are choosing to make these modifications, and if * you point the finger at me for messing up your device, I will laugh at you. * BOOM goes the Dynamite */
I am releasing this kernel because I like to share my work and have had requests to do so and, lastly, because we needed yet another kernel released for our beloved OP3! I started out at XDA because I wanted to learn and share what I have learned. My goal with this kernel is to be a very fast and stable build that offers some things that the other kernels do not. I also want to initiate Development Discussions among the community. This will be a noob friendly thread as long as users follow two rules. First is to do some research before asking. Most likely your question has already been asked. If not in this thread then in another. Remember to always search first! Second is BE RESPECTFUL. You do these two things and even the most hardened Dev will assist you.
Wanna be notified of an Update? Here is my PushBullet Channel!!
https://www.pushbullet.com/channel?tag=renderkernel
Current Features
General List:
* EAS Only
* Built with LINARO 6.x
* Updated with CAF LA.UM.5.5
* IO Scheds - FIOPS, CFQ, BFQ, ROW, DEADLINE, NOOP, and ZEN Schedulers
* Flar Sound Control
* Wake Gestures - DT2W, S2W, and S2S
* Complete Color Calibration Thanks to @savoca
* F2FS Support
* Adrenoboost
* USB Fast Charging
I recommend Kernel Aduitor for making kernel changes
Kernel Downloads:
LOS-(EAS/HMP) Downloads
OOS-(EAS/HMP) Downloads
Instructions:
* Boot into Recovery
* (Recommended) Make a complete backup of everything!
* At least backup BOOT via TWRP
* Flash Zip
* Reboot
THANKS!!!!
First I want to say thank you to everyone who has answered my questions and responded to my pm's when I know they are busy with their own lives. Pretty much everyone I have come into contact with here on XDA has been truly helpful and respectful. Here is a list of people that had helped me in one way or the other:
Neobuddy89, ak, myfluxi, Dorimanx, Savoca, Faux123, DespairFactor and Many More!
Thank you guys! Without your contributions to the community we would not have the level of performance, stability and interaction that we have today
Special Thanks!
Donators: @nfin1te, @MrDarkKV, @V1TRU, @Really now @erad1
Source Links:
https://github.com/RenderBroken/OP3-kernel
https://github.com/RenderBroken/OP3-LOS-kernel
https://github.com/RenderBroken/RenderKernel-AnyKernel2
XDA:DevDB Information
[UNIFIED] Render Kernel [OOS-N-EAS-R2][LOS-N-EAS-R8], ROM for the OnePlus 3
Contributors
RenderBroken, Mostafa Wael, joshuous
ROM OS Version: 7.x Nougat
Version Information
Status: Testing
Created 2016-11-23
Last Updated 2017-12-1573
I have finally finished my other endeavors and will be focusing on the op3(t). I am excited to show you guys what @joshuous and I have in store for you all. We have been planning our o-eas work for sometime now and I feel confident that we will surpass what we did on N. I appreciate the patience from everyone while allowing us to pursue our projects in peace. It just goes to show that we have the best community out there.
Soon....
70Note:
Great write-up from @Mostafa Wael
HMP vs EAS - OxygenOS 4.1.3 stable
Right here we go!
First things first, this is a comparison between two kernels and NOT just two different scheduling systems. With the latter being undeniably the biggest difference between RenderKernel and the stock kernel, changes can extend to other default settings, should @RenderBroken choose to do so. One of which is the default choice of BFQ I/O scheduler instead of the default CFQ I/O scheduler of stock kernel. If you want to have a quick debrief of what (the current implementation of) EAS is all about, read this post here
MMX Hill Dash
HMP - most of the time the game is mainly operated by the big cluster while the little cluster is mostly at the lower end of the frequency table, hovering around the absolute minimum frequency of 307 MHz for most of the time. The big cluster however was noticeably more active, hovering around 1.25 GHz to 1.55 GHz with rare dips below 1 GHz and slightly more often spikes to 1.7 GHz and above. So to sum up HMP's management of the CPU in this particular game, it is safe to state that the game is more or less solely operated by the big cluster, running mostly on the intermediate frequency steps between 1.25 GHz and 1.55 GHz with occasional spikes to 1.7+ GHz and much scarcer dips to sub 1 GHz. As far as performance goes, there are no major complaints. The game runs incredibly smoothly and the game is loaded in a reasonably quick manner; launching the game takes between 8s and 10s from the get-go.
EAS - It's remarked that all 4 cores are active when playing this game, unlike HMP, with the little cluster spending almost all of the time at the 1.11 GHz step with very rare dips to the minimum frequency. While that may sound like a bummer, there is an upside to the surprisingly increased activity of the little cluster. Apparently the big cores have some of the loaded lifted, since the big cluster is being utilised at noticeably lower frequency steps compared to HMP, staying on the 1.11 GHz frequency step much more often, otherwise roaming between 1.25 GHz and 1.55 GHz with very scarce spikes to the max frequency. Like HMP, the game runs flawlessly with no major complaints and surprisingly the game is loaded just as quick as HMP too, if not a tad quicker sometimes! Crikey!
True Skate
HMP - Both clusters are heavily fluctuating with no predictable trend. However, it is quite noticeable that the big cluster can hit the high end of the frequency table quite often. Little cluster is relatively less active, but it is not that dormant either. With that said, it is no wonder that the game runs silky-smooth. However, there were some instances where the frame rate would suddenly drop to around 40-45 fps for mere seconds, where the cause has been determined to be some background tasks being executed like Play Store checking for whether there are apps need to be updated, and social media apps refreshing in the background. Theoretically such an issue would not exist on EAS due to cleverer tasks placement techniques to avoid overstressing the CPU.
EAS - Both clusters spend most of their time at the 1.11 GHz frequency step, with the big cluster ramping up to the max frequency for a considerable amount of time. With that said, a natural consequence would be witnessing one of the most consistently smooth and fluid gaming sessions of that particular game. And even with lots of background processes taking their toll on the silicon, performance is not hindered by any means.
Browsing via Chrome
HMP - Flinging through the webpage will immediately crank up the big cores to max frequency straight away till the content is loaded. Should there be a video to be buffered, the big cores keep operating at medium high frequencies between 1.25 GHz and max frequency with rare dips to minimum frequency. Once all contents are loaded, the big cores gradually get toned down and caged into the lower end of the frequency table. The little cores on the other hand are not wrestling with the controls surprisingly enough, rather sitting most of the time comfortably at 0.96 GHz to 1.1 GHz, with a considerable amount of time spent on the lowest two frequency steps of 307 MHz and 422 MHz. Scrolling through the webpage is reasonably smooth, though sometimes it tends to be a bit unresponsive and wonky if a lot of interactions were present or a lot of content are being loaded while scrolling. As far as battery backup goes, there is no escape that such a task would sip a lot of juice from that tank. And at 18%/hr, there is a lot to be desired when it comes to efficiency, bearing in mind that such a high active drain rate does not guarantee you a flawless silky-smooth UI.
EAS - Like HMP, flinging through the webpage will engage the big cores fully till the page contents are loaded. However, unlike HMP, the big cores do fade out quite faster when the page contents are loaded successfully. Things get much better when there is a video to be streamed, where the video is mainly handled by the little cluster while the big cluster is impressively tamed and utilised at sub 1 GHz frequencies, 0.7 GHz on average, while the little cluster lifts the burden from the furious big cores, operating at frequencies between 1.1 GHz and max frequency of 1.59 GHz. Scrolling through the pages is silky smooth with no hiccups of any sort, even when loading a lot of content while stubbornly scrolling the page, it does not stutter as much as it does on HMP. However, things are not all rosy when it comes to battery drain. Web browsing is undeniably demanding, which makes it logical to see a not-so-impressive 17%/hr drain rate. While it may sound marginally better, web browsing inevitably does take its toll on the battery for sure, and things are not that drastically better when it comes to battery conserving. However, when you couple that with the increased fluidity and consistency gained, EAS is the clear victor.
YouTube streaming
HMP - For such a medium/light workload, it is no wonder seeing the little cluster being noticeably more active than the big cluster, where it spends most of the time on the lower end of the frequency spectrum, with more than 60% spent on the lowest 2 frequency steps of 422 MHz and 307 MHz. However, there were some occasional bumps to a rather unexpectedly higher frequency of 960 MHz, taking around 11% of the total time. While the big cluster was relatively quite dormant, it was not asleep either. With around 7% of the time spent on 1.25 GHz, it is far from being asleep, which raises some eyebrows for sure. It's not that grim though. At 11.6%/hr drain rate, it's highly unlikely to find your phone depleted before lapping some 9 episodes of your favourite TV series, which in my case was the old Top Gear UK.
EAS - Surprisingly enough, there are almost no tangible improvements in battery life while streaming some videos on YouTube. With the consistently reported figure of 11.3%/hr by EXKM battery monitor, I am struggling to say anything other than the fact that battery life is very similar to that of HMPs. Moreover, the frequency distribution is not that all different either. Little cluster is expectedly sitting most of the time at the lowest two frequency steps with much shorter duration at the 480, 556 and 652 MHz steps. Same goes for the big cluster as well, with respective frequency steps considered of course. But rest assured, it is still as highly unlikely to miss out a season of your favourite TV series as with HMP.
Overall battery life
HMP - in the past couple of days, I often read a value between 14%/hr and 16%/hr in EXKM's battery monitor with my mixed not-so-light usage, which is pretty much decent though not perfect and definitely leaves something to be desired in that area. But since I get more than 5 hrs SOT at the end of the day with some little juice left in the tank at the end of the day, I think it is safe to say battery life is good enough for the overwhelming majority of users
EAS - While people may think this is pure EAS terrain, results are not dramatically different from what you get from HMP. Surprisingly enough, I often stumble across an active drain rate between 13%/hr and 15%/hr with approximately the same usage pattern, which is 3%/hr less than what you get from HMP in the best cases. This is a substantial improvement, make no mistake, but that may not live up to the expectations from an energy aware scheduling system. However, an area where EAS truly shines is screen-on idling. Not only does the CPU retreat to the minimum frequency quite quickly, but also remains utterly dormant with absolutely no random spikes, causing a dramatic decrease in the battery drain. This is purely e-book readers heaven for sure! The same cannot be said about HMP for sure.
let's get to the numbers...
App launches
[HMP]
PCMark: (7.13 + 8.32 + 6.65 + 7.00 + 7.85)/5 = 7.39 sec
Slack: (1.60 + 1.78 + 1.79 + 1.65 + 1.75)/5 = 1.71 sec
YouTube: (1.40 + 1.44 + 1.41 + 1.44 + 1.45)/5 = 1.43 sec
Telegram: (0.65 + 0.72 + 0.70 + 0.54 + 0.61)/5 = 0.64 sec
WhatsApp: (1.28 + 0.72 + 1.27 + 1.34 + 1.28)/5 = 0.91 sec
Hangouts: (1.38 + 1.34 + 1.31 + 1.34 + 1.38)/5 = 1.35 sec
Dropbox: (1.25 + 1.26 + 1.37 + 1.22 + 1.21)/5 = 1.26 sec
Chrome: (1.18 + 1.36 + 1.19 + 1.50 + 1.38)/5 = 1.32 sec
Keep: (0.94 + 1.03 + 0.97 + 0.94 + 0.97)/5 = 0.97 sec
MMX Hill Dash: (7.56 + 12.87 + 12.09 + 11.60 + 10.81)/5 = 10.99 sec
Twitter: (1.69 + 1.81 + 1.90 + 1.66 + 1.91)/5 = 1.79 sec
True Skate: (1.60 + 1.69 + 1.62 + 1.59 + 1.54)/5 = 1.61 sec
XDA Labs: (1.41 + 1.53 + 1.47 + 1.48 + 1.52)/5 = 1.48 sec
Test has been done with no active Internet connections (WiFi and mobile data turned off) to ensure that the phone is not bottlenecked by anything but the I/O and the CPU
CPU governor is Interactive with stock settings and I/O scheduler set to CFQ with 512 KB read ahead buffer size
[EAS]
PCMark: (9.13 + 9.63 + 9.50 + 9.84 + 9.50)/5 = 9.52 sec
Slack: (1.66 + 1.79 + 1.69 + 1.75 + 1.85)/5 = 1.75 sec
YouTube: (1.66 + 1.69 + 1.63 + 1.62 + 1.69)/5 = 1.66 sec
Telegram: (0.69 + 0.66 + 0.63 + 0.59 + 0.78)/5 = 0.67 sec
WhatsApp: (0.75 + 1.19 + 1.16 + 0.97 + 1.21)/5 = 1.06 sec
Hangouts: (1.34 + 1.29 + 1.36 + 1.25 + 1.31)/5 = 1.31 sec
Dropbox: (1.40 + 0.84 + 0.86 + 0.85 + 0.87)/5 = 0.96 sec
Chrome: (1.32 + 1.37 + 1.39 + 1.56 + 1.32)/5 = 1.39 sec
Keep: (0.97+ 0.91 + 0.85 + 0.93 + 0.84)/5 = 0.90 sec
MMX Hill Dash: (11.31 + ---) the game refuses to launch seamlessly, to be investigated later..
Twitter: (2.25 + 2.53 + 2.50 + 2.57 + 2.37)/5 = 2.44 sec
True Skate: (2.00 + 1.58 + 1.71 + 1.75 + 1.74)/5 = 1.76 sec
XDA Labs: (1.72 + 1.44 + 1.47 + 1.53 + 1.43)/5 = 1.52 sec
Test has been done with no active Internet connections (WiFi and mobile data turned off) to ensure that the phone is not bottlenecked by anything but the I/O and the CPU
CPU governor is Schedutil with stock settings and I/O scheduler set to BFQ with 512 KB read ahead buffer size
.
Synthetic Benchmarks
[HMP]
AnTuTu: 148,471
Geekbench 4.1.0: 1733 + 4191
Vellamo - Multicore: 3215
Vellamo - Metal: 3541
Vellamo - Chrome: 4825
[EAS]
AnTuTu: 143840
Geekbench 4.1.0: 1740 + 3290
Vellamo - Multicore: 2511
Vellamo - Metal: 3569
Vellamo - Chrome: 4350
This test was conducted with RenderKernel-OP3-OOS-N-EAS-R1-WALT and OnePlus's inbuilt kernel. OxygenOS version used was OOS 4.1.3 STABLE
Coming up next is a brief technical breakdown of OOS's behind-the-scenes stuff and how OnePlus fiddled around with them by XDA member @chinmai560621 .
Hope such an analysis benefits someone here. Sorry for the delay, but i have been double slapped by life for the past couple of weeks every day....59RK-LOS-N-EAS-R4 is HERE!!!
Things to note:
This build has been a huge project. Not only was I doing this work for the OP3(T), I was doing this work to lay down the groundwork for other Devs to port and use to bring EAS to their devices. I have collaborated all over XDA. If we can get EAS taking off faster, then maybe more OEMs can see the benefits of it. I have rebased, my rebase, of a rebased rebase and finally landed on what we are using today. I have thoroughly testing with the LISA Toolkit from ARM. Then I added all the normal Render Kernel features that DID NOT create performance regressions. Now, we have R4. I have build a PELT and WALT variant. Right now I prefer and recommend WALT. This is QCOMs solution to Load Tracking and is very interactive. PELT is in mainline linux and uses CFS (Completely Fair Scheduler) as its base and uses Load Decay. This one ramps up and down slower. So the fast load changes where WALT may cause SCHEDUTIL to lower frequency, PELT may continue to carry the load through this period. In theory that is. For Me WALT seems to just be better all around but the future goals of EAS is to have PELT become more competitive with WALT.
You have a questions? Ask it! There is only one way to learn and that is by digging in. Please let me know how it works for you.
Download
Changelog53Hey guys!
Sorry for being absent of late. Just been busy as hell again. So much so that even in my free time, I just had to take it easy. I did get the OP5 as well and love it! The jelly effect is such a minor annoyance but it is still an annoyance. Though it's so minor that the OP5 is still the greatest bang for the buck. Main thing for me was to bring EAS to the SD835. So far I am blown away with the OP5 as the performance gain over the OP3 is dramatic IMO. The battery gain as well is dramatic when compared to my OP3. I will be continuing development for the OP3 as well for those curious. I am hoping to bring both phones inline enough with each other so that I can just make the same changes to all kernel builds I am doing. I have alot more EAS changes incoming as well. I just wanted to give an update for those interested. Thanks guys for all the support here and in my Slack Group.
Kind Regards,
Render
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone