Related
Okay, let's try not to get this thread cluttered up with off-topic speculation like the last one. Starting with what we know already:
There is a ~30 frames per second cap on 2D and 3D rendering. This can be established both visually (play Doodle Jump) and through a benchmark.
If you boot a Nexus One 2.2 ROM, the animation seems to run at 60FPS for a while. This, however, is not totally certain.
This seems to be a software cap, not a hard cap. However, an HTC product representative says otherwise. Jury's still out, apparently.
There is speculation that the cap might be due to the HDMI out on the graphics chip.
Kernel source is being released "soon".
There is touch sensing lag, but this seems to be unrelated.
This issue affects all EVO hardware builds and all EVO ROMs currently.
HTC claims that the cap is by design to improve battery life.
If there is anything else that you have to add that has reasonable evidence backing it up, please do.
EDITED BY TOASTCFH:
Issue of 30fps has been resolved on the devices with Epson pannels through the work done on the kernel reverse engineered kernel source provided in the thread below. for more information and source code for the fix/fixes. also a update.zip can be found on the OP for Fresh 0.3 containing a boot.img containing the kernel compiled with the fps fix.
{KERNEL-SOURCE} GoDmOdE-EVO-2.6.29 {Make Shift Kernel}
enjoy
END OF EDIT
Correct me if I'm wrong but while running fps2d, aren't there slight flashes where the fps jumps over 30? That in and of itself should prove that the cap isn't hardware based.
Krandor311 said:
Correct me if I'm wrong but while running fps2d, aren't there slight flashes where the fps jumps over 30? That in and of itself should prove that the cap isn't hardware based.
Click to expand...
Click to collapse
Very true! I'm not versed very well in the actual mechanics of the hardware, but that does sound like a good sign.
well, a good idea to see if it's a hardware cap or whether it's with the kernel is to try using toast's ported incredible kernel? since the incredible doesn't have the 30fps issue, and assuming it's software(kernel) based, then we shoudln't have that problem.
someone willing to try? sorry, i can't do this on my evo at the moment
I would try if I had the kernel made for me in zip format to flash. Since I have one of the I/O devices I would be able to try but I dont know how to make the kernel to flash.
This thread is gonna get merged...
timgt said:
I would try if I had the kernel made for me in zip format to flash. Since I have one of the I/O devices I would be able to try but I dont know how to make the kernel to flash.
Click to expand...
Click to collapse
Try one of the overclock builds. They are using toast's source. I want to think this has been tried before.
EDIT:
Seems it was tried on these builds:
RvU Rom: On android central
AOSP Rom: Avalaunch's AOSP Rom
FroYo Rom : Avalaunch's FroYo Rom
http://forum.xda-developers.com/showpost.php?p=6769032&postcount=88
Vinny75 said:
Try one of the overclock builds. They are using toast's source. I want to think this has been tried before.
Click to expand...
Click to collapse
I'm pretty sure it has and still has the same issues the board files for the evo are in there though not the incredibles
I don't think it is firmware. The RUU for the EVO and Incredible both contain the same tp_amtel224_16ab.img which may be the firmware for the Amtel 224 touchscreen controller. (http://forum.xda-developers.com/showthread.php?t=704640)
From ffolkes
i've been working on this all day. literally. about 9 hours straight.
this is what i've found. changing the mddi clk_rate to anything but 384000000 results in it getting set to 117965000 according to dmesg. now 384/20 = 19.2 which is precisely the frequency of TCXO. seems a bit odd. it's also exactly half of the other clock defined, GLOBAL_PLL at 768mhz. PLL1 (core) is also 768. another clock is defined, AXI at 128mhz, that acronym is mentioned in the video/gpu drivers. not sure if that's related to that clock, or just some video thing i'm not familiar with and completely unrelated.
changing PMDH_CLK (in devices.c) to OFF | MINMAX or just MINMAX *AND* changing the mddi freq to anything higher than 384000000 results in dmesg saying mddi was set to 235930000 (instead of 117965000) but i still get the same 30fps id get if it was at 384000000. so when you think about it, this means mddi can't be capping it, otherwise i'd see a difference between 235930000 and 384000000. but they're exactly the same fps. it HAS to be happening elsewhere.
i've also found removing the adreno200 drivers from /system/lib/egl results in a silky smooth sprint boot animation, the gui flickers crazily, but fps2d still shows 29. perhaps this is what people were seeing with the froyo boot animation looking smooth.
you know, this 29fps thing is very specific...ntsc is 29.97fps. coincidence? i really don't think so. fps2d always averages out to 29, not 30.
i also tried removing all the hdmi code in the board files, that didn't change anything.
i find it very unlikely this is hardware limited though. the gpu is on die with the cpu, so unless htc had qualcomm make them a custom chip, it's all software controlled. there's nothing to suggest the gpu has its own crystal on the pcb. i mean, if we can completely control the cpu frequency via software, the same stands to reason with the gpu.
if it was something hdmi hardware related, it should be able to be disabled in the kernel and the evo wouldn't even know it was there, just like with the sensors that don't work.
it appears the evo uses a SIL9022A for hdmi, which makes no mention of requiring any change to the lcd frame rate. (http://www.siliconimage.com/products...t.aspx?pid=150)
Click to expand...
Click to collapse
from http://forum.xda-developers.com/showpost.php?p=6854074&postcount=664
I did a little experiment to see if the restriction was in user-space or the kernel:
- First I set up my machine like I described in the "Getting a wider set of development tools on the phone" thread
- Then I wrote a little program (attached) that suspends the phone compositing manager and wrote to the frame buffer device directly.
The conclusion: Even when writing straight to /dev/graphics/fb0, talking straight to the kernel, there's a 30fps limit.
halfline said:
I did a little experiment to see if the restriction was in user-space or the kernel:
- First I set up my machine like I described in the "Getting a wider set of development tools on the phone" thread
- Then I wrote a little program (attached) that suspends the phone compositing manager and wrote to the frame buffer device directly.
The conclusion: Even when writing straight to /dev/graphics/fb0, talking straight to the kernel, there's a 30fps limit.
Click to expand...
Click to collapse
So does this hint that it's a board driver issue and not a hardware issue? Is the fps being sent to fb0 already at 30fps? Sorry, just trying to understand. Been working on this issue for days too.
AssassinsLament said:
So does this hint that it's a board driver issue and not a hardware issue? Is the fps being sent to fb0 already at 30fps? Sorry, just trying to understand. Been working on this issue for days too.
Click to expand...
Click to collapse
I think it would be very strange if it were a hardware issue, but this test unfortunately doesn't help answer that question.
As far as I can tell, the way drawing works on the phone is... Every app communicates with this "system_server" compositor process. That compositor is what sends the drawing to the framebuffer device. The individual apps use shared memory to share what they want drawn with the compositor.
The question I was trying to answer was. Is the system_server compositor limiting the framerate, or is it the kernel? My program takes the compositor out of the picture, and just does some very fast drawing straight to the framebuffer device as quickly as possible. It measures the framerate at which the drawing is getting processed by the kernel. If I let it run for a while the output is like:
30 frames in last second, 29.7 average fps, total time 102 seconds
which leads me to believe it's definitely not the compositor (or say userspace libraries) imposing the 30fps framerate.
halfline said:
I think it would be very strange if it were a hardware issue, but this test unfortunately doesn't help answer that question.
As far as I can tell, the way drawing works on the phone is... Every app communicates with this "system_server" compositor process. That compositor is what sends the drawing to the framebuffer device. The individual apps use shared memory to share what they want drawn with the compositor.
The question I was trying to answer was. Is the system_server compositor limiting the framerate, or is it the kernel? My program takes the compositor out of the picture, and just does some very fast drawing straight to the framebuffer device as quickly as possible. It measures the framerate at which the drawing is getting processed by the kernel. If I let it run for a while the output is like:
30 frames in last second, 29.7 average fps, total time 102 seconds
which leads me to believe it's definitely not the compositor (or say userspace libraries) imposing the 30fps framerate.
Click to expand...
Click to collapse
Ok, thanks. Here is what I've tried so far:
I've taken the full stock HTC Incredible source (similar device), and just put in 9 board supersonic files into it, changed the makefile to compile those supersonic specific files and the kernel boots and everything is fine, but its still capped at 30fps. The HTC Incredible does not have the 30fps issue, so it's 1) code that I can't find in those 9 board supersonic files, or 2) Hardware capped.
That's my best thoughts for now on it
I think it has to do with the htc lock screen. The lockscreen is difficult to remove in custom roms (i haven't seen anybody do it yet) and when you run fps2d with the screen off you get 60 fps (or like 57)
Hey... you guys do know that720p LCD HDTVs display at 30Hz right? Newer ones do 240 and whatnot, but if you have an LCD monitor that's high def (like our evos), play with the refresh rate... just saying
Tilde88 said:
Hey... you guys do know that720p LCD HDTVs display at 30Hz right? Newer ones do 240 and whatnot, but if you have an LCD monitor that's high def (like our evos), play with the refresh rate... just saying
Click to expand...
Click to collapse
I don't think any one here knows that. At least anyone that has done their homework.
-Roger
hibby50 said:
when you run fps2d with the screen off you get 60 fps (or like 57)
Click to expand...
Click to collapse
If that is true, wouldn't this be evidence that it is not hardware capped?
roghaj said:
I don't think any one here knows that. At least anyone that has done their homework.
-Roger
Click to expand...
Click to collapse
I don't know what thats supposed to mean so ill ignore it...
How about trying the straight to kernel test on avalaunchs' froyo v8 with the OC revision flashed? seems like something different... custom kernel, overclocked, and the cameras not working could be a plus for the benchmark... hopefully hdmi is dead too....
Does anyone know if the hd2 has this issue doesn't it have the exact same screen and alot of the same hardware as the evo just different OS
This kernel module allows you to run any stock HTC Froyo kernel with lowered CPU voltages. Reducing voltage decreases power consumption by the CPU, thus lowering heat and increasing battery life.
INSTALL:
You need root or an unrestricted recovery image (e.g ClockworkMod) to install this. The default settings decrease voltage by 75-100 mV which seems stable on my device (HTC Desire) and is reported to be fine on the EVO. Just download the attached file and select it from recovery or ROM Manager.
I've built "update.zip" files for the EVO 4G with Linux kernel versions 2.6.32.15-g746f4f0, 2.6.32.15-ge2fb08e, and 2.6.32.15-g59b9e50. You can check your kernel version in Settings->About phone->Software information.
Other HTC devices running Froyo are supported. If you have a different device, please give me the full version number and I can add an update.zip for it.
Full details and source are in the original thread in the Desire forum:
[KERNEL] Undervolt driver for the stock HTC kernel for Desire and others (2.6.32.15)
Update, 2010-11-22: Added driver for 2.6.32.15-ge2fb08e.
Update, 2010-11-23: Added driver for 2.6.32.15-g59b9e50.
recant: love this idea when trying to keep this stock
Sounds like it would go well with Fresh's new rom.
ericwgarza1 said:
Sounds like it would go well with Fresh's new rom.
Click to expand...
Click to collapse
+ 1 on that I agree
sweet I like. Does it change the kernel version?
Too weak... funny considering there is more work involved in setting this up than most linux guys even do on a pc... let alone a phone.
tatnai said:
what's this here? sounds like an add on for those too weak at heart to flash a modded kernel. will likely find some friends, strong work.
Click to expand...
Click to collapse
Sent from my PC36100 using XDA App
tatnai said:
what's this here? sounds like an add on for those too weak at heart to flash a modded kernel. will likely find some friends, strong work.
Click to expand...
Click to collapse
Maybe not. I run the netarchy kernel but don't OC because it seems to crash at random times. I use it because the battery life is better than stock.
I'll revert to a clean back-up and give this a try just for giggles.
I would like to see some results.
I say that because I have tried a few havs roms and get worse battery life.
I think what a lot of people don't realize unless they are heavily into overocking is that microadjustments just dont have much effect there needs to be some substantial drops to really have any effect on battery and heat.
I realize that this is no desktop or laptop cpu, and that this cpu is based off such low voltages but such minor voltage adjustments, 80-100mv just arent going to have the desired effect unless that equates to a "substantial" voltage drop.
Not to mention the fact that most of you are going to overclock your phone without the faintest idea that doing so, even with a lower cpu voltage, will still cause worse battery life. This is a fact.. to argue it is futile. Its the nature of the beast.. do some reading and find out for yourself.
You can overcome some things by using on demand overclocking but you have to do extensive testing to find the sweet spot.
fr4nk1yn said:
Maybe not. I run the netarchy kernel but don't OC because it seems to crash at random times. I use it because the battery life is better than stock.
I'll revert to a clean back-up and give this a try just for giggles.
Click to expand...
Click to collapse
Sent from my PC36100 using XDA App
Nice work. I'm not interested in oc'ing, nor flashing a custom kernel. I may give this a go after a few others check in w/ results. I just want to know that it's stable.
I went to your other thread and saw the source. Clever solution, nice work. I really do like that you wrote a device to /proc that does a little more than report the frequencies back. This will make it very easy to write some scripts, or even a UI, that lets me tweak the settings. Hopefully I have some time to work on that in the upcoming weekends.
Will take a look at this first chance I get. Trying to finish my battery logger since everything available now doesn't log exactly what I want to know. Kudos.
Does this make HAVS obsolete ?
iscaela said:
This kernel module allows you to run any stock HTC Froyo kernel with lowered CPU voltages. Reducing voltage decreases power consumption by the CPU, thus lowering heat and increasing battery life.
INSTALL:
You need root or an unrestricted recovery image (e.g ClockworkMod) to install this. The default settings decrease voltage by 75-100 mV which seems stable on my device (HTC Desire) and is reported to be fine on the EVO. Just download the attached file and select it from recovery or ROM Manager.
I've built "update.zip" file for the EVO with Linux kernel version 2.6.32.15-g746f4f0. You can check your kernel version in Settings->About phone->Software information.
Other HTC devices running Froyo are supported. If you have a different device, please give me the full version number and I can add an update.zip for it.
Full details and source are in the original thread in the Desire forum:
[KERNEL] Undervolt driver for the stock HTC kernel for Desire and others (2.6.32.15)
Click to expand...
Click to collapse
Undervolting meaning only when screens off or on and off ?
I installed and will get the best battery life yet. Better than when I was with King and other kernels....thanks!!!
Anyone have any results from flashing this yet? How is battery life? Any stability issues?
look4wisdom said:
Anyone have any results from flashing this yet? How is battery life? Any stability issues?
Click to expand...
Click to collapse
No stability issues and it seems to help on battery a little bit but I really can't tell a big deference. I was expecting for it to help out more. Thanks anyways OP for the share
i did say those little microvoltages aint gunna make any difference.
plus if you try to overclock you just cancelled any lowered voltages and actually cause higher power draw than stock mhz at stock voltages.
higher mhz equals higher power draw whether you have it undervolted or not.
you have to make a signifigant drop in voltage to make any difference at all. let alone if you try and overclock.
not trying to dog the guy who discovered this i am just sing plain and simple math, heat, and electronic voltages.
Sent from my PC36100 using XDA App
question there a some diference between this kernel and the once from King and Net, talking about battery life and performance
juancaperez2000 said:
question there a some diference between this kernel and the once from King and Net, talking about battery life and performance
Click to expand...
Click to collapse
This isn't a kernel its just a couple of files that go with the kernel. One file for initial boot ect/initd and a .ko file that goes in system/lib/module folder.
I have an Evo, [email protected] #11. I would like to try it. Please build an update.zip to support it.
Cheers.
snovvman said:
I have an Evo, [email protected] #11. I would like to try it. Please build an update.zip to support it.
Cheers.
Click to expand...
Click to collapse
OP
Sent from my EViO + PURE= PURE Baked EViO
PaulB007 said:
If you haven't been able to get past the HTC screen at boot and keep bootlooping, YOU MUST INSTALL BC'S 1.5 GHZ KERNEL FIRST AND THEN FLASH THESE KERNELS OVER THAT I also just flashed it straight off of a new Mikshift install and I got the bootloop until I did this. So if you guys didn't do this, then install bc's kernel and flash Scary kernel again.
Scaryghoul, I have installed your 1.8 suv successfully on Mikshift. This is great news. I knew it would work, but for some reason I just cant get it running on aosp. I will keep you updated on IRC or through this thread, I haven't seen you on today yet.
Click to expand...
Click to collapse
Link to bcnice20's 1.5ghz kernel: http://forum.xda-developers.com/showthread.php?t=941728
If that doesn't work, try flashing over his 1.8ghz kernel(This is what worked for me, bcnice, if you want me to take down this link just let me know.) - http://thebcblends.com/shift/kernels/Sense-1.8ghz-bfq-test1.zip
Table of contents:
Intro
Features/what this includes
Why it's labeled unstable
Disclaimer
Latest kernels
Instructions for using swap
Governor exlainations
Governor strategies
Recommended apps
Locating cpu% Eaters && other negative items towards battery life
FAQ!
Changelog
Stable/safe voltage kernels
Notes
Source
Credits
Intro: I'm scaryghoul.
What this includes
Swap
BFQ I/o scheduler
Extreme undervolt
Overclocked & underclocked values
HW3D enabled
Sleepers disabled
Smartass governor
New Scary governor!
Tweaked conservative governor
and much more(All of bcnice20's kernel)
Why it's labeled unstable: So I don't get people poking me in the eyes with spoons if/when it freezes up. It actually works quite well, but since I heavily undervolted an undervolted kernel, it is bound to not be 100% stable(It is about 90% stable =P)
Disclaimer: What everyone else puts in kernel threads, about me not being responsible, ect.
Latest kernels
The voltages of the superUV will not work for everyone, if they don't work for you, then try the builds labeled stable
Recommended speeds 245-800mhz or 245-1ghz on scary governor && no setcpu profiles
Scarykernel 1.8 suv - http://dl.dropbox.com/u/15373824/Sense/ScarySense1.8Suv.zip
Scarykernel 1.8 stable undervolt - http://dl.dropbox.com/u/15373824/Sense/ScarySense1.8Stable.zip
Instructions for using swap
For a swapfile do something like this.
dd if=/dev/zero of=$Swapfile bs=1048576 count=$Size
Where $Swapfile is the location of the file you want, and $Size is the amount of mb for swap you want to use.
Then type
mkswap $Path
swapon $Path
Replacing $Path/$Size with your own values of course, so if I wanted 20mb of swap I'd execute the commands
dd if=/dev/zero of=/sdcard/swapfile bs=1048576 count=20
mkswap /sdcard/swapfile
swapon /sdcard/swapfile
Governor exlainations
Toasty makes one transition to the max speed and stays there(benchmarks only usually)
Batterysave! sits at the bottom and when the cpu load increases past the threshhold it scales up to the next speed and takes another load sample and keeps doing that(best on battery life/performance ratio)
Ondemand sits at the bottom and when the cpu load increases past the threshhold, it scales ot the max speed then takes another load sample and scales down accordingly
Powersave makes one transition to the bottom speed and stays there
Smartass(Quoted from another author http://www.ziggy471.com/2010/11/07/smartass-governor-info ) - "is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works – by taking over the idle loop – is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the “old” minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 – why?! – it will cap it to your min frequency). Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more!"
Scary - A new governor I wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.
Governor strategies
Conservative - Upthreshold 85, downthreshold 60
Smartass - Sleep max 245760Hz, Ramp up at 384000Hz at a time, up threshold 90, downthreshold 60
Scary - Upthreshold 80, down threshold 45, sleep max 245760Hz, sleep min, 122880Hz
Recommended apps =)
Zdbox - Great toolbox app, just don't let it run in your notifications bar, it's a cpu eater
Setcpu/Nofrills - Apps that help manage your cpu/profiles/ect.(I don't use them but they're pretty okay)
Perfect system or Elixer widgets - Widgets that monitor battery, current, cpu%, cpu speed, and more(Great for battery guru's)
Adw ex - Smoothest/fasted/lightest ratio in a launcher I've seen so far, and least cpu intensive(for me that's a big thing so the cpu scales less)
Colorize widgets - Great widgets to replace the lpp ones for those converting to other launchers.
AppMonster(pro or free) - Great backup utility, automatically backs up all apps.(I like it better than TB)
GPS Status - Great application for finding satalites near you and helping get a quick lock.
Any go dev team app - Great dev team, all their apps are worth looking at.
Frequently asked questions
Question: My phone is boot looping/not booting on the released suv, what do I do?
Answer: Your phone cannot handle the super undervolted values, you will need to flash the stable undervolted kernel
Question: My phone is running slow on the batterysave or scary governors, what do I do?
Answer: Set your minimum speed higher, those governors spend a lot of time at the lowest values
Question: How do I flash this?
Answer: You probably shouldn't be flashing one of my kernels if you don't know how(Mine are unstable =P)
Question: I'm not getting the amazing battery life/benchmark scores that others are getting
Answer: Well, every device is different, so you may not be able to score as high as some others, but you should get close at least, and the battery completely depends on usage patterns
Question: My phone can't clock to 1.8ghz, or some of the other higher values but does fine on the lower ones
Answer: Every device is different and not all can handle the same speeds/voltages, you are probably better off staying away from the higher speeds, I enabled the speeds but hope that you all are mature enough to handle them
Locating cpu% eating applications.
When in ADB shell type the following
top |grep app
Then look for items with high amounts of cpu% while the phone is idle.
Changelog
v1.8 - Initial kernel release for sense
Safe voltage kernels
v1.8
Scarykernel 1.8 stable - http://dl.dropbox.com/u/15373824/Sense/ScarySense1.8Stable.zip
Notes:
No I can't take the overclock any higher, I think everyone who's had a chance to take a crack at this source has tried, and going any higher seizes up after a few seconds.
Here is the source code for this build. I'll try to maintain it, I have a lot of kernel sources, but this will always be the latest release code, unless I state otherwise.
https://github.com/Scaryghoul
Credits: bcnice20 - For 99.8% of his kernel source.
Dogejcr/Preludedrew - For helping me get my laptop setup for kernel compiling.
Testers - For flashing this even though it says unstable :-X
JoesephMother - For helping me unlock the new lower clock values && other kernel related matters =)
x99percent - I used his middle clock speeds between the 3xx->7xx values as a base(edited voltages) as well as used his smartass source.
I see nobody else has chimed in on this kernel yet.. I will install Mikshift tomorrow and report my findings.
Bummer, my phone is a wuss! I can't boot either one of these. Just sits on white screen. They look cool as hell though.
Sent from my PG06100 using Tapatalk
Yeah both versions don't work on mine.
If you haven't been able to get past the HTC screen at boot and keep bootlooping, YOU MUST INSTALL BC'S 1.5 GHZ KERNEL FIRST AND THEN FLASH THESE KERNELS OVER THAT I also just flashed it straight off of a new Mikshift install and I got the bootloop until I did this. So if you guys didn't do this, then install bc's kernel and flash Scary kernel again.
Scaryghoul, I have installed your 1.8 suv successfully on Mikshift. This is great news. I knew it would work, but for some reason I just cant get it running on aosp. I will keep you updated on IRC or through this thread, I haven't seen you on today yet.
Tried going strait from BC's still no go.
Sent from my PG06100 using Tapatalk
ozzie1p said:
Bummer, my phone is a wuss! I can't boot either one of these. Just sits on white screen. They look cool as hell though.
Sent from my PG06100 using Tapatalk
Click to expand...
Click to collapse
Did you flash over bcnice20's kernel?
PaulB007 said:
If you haven't been able to get past the HTC screen at boot and keep bootlooping, YOU MUST INSTALL BC'S 1.5 GHZ KERNEL FIRST AND THEN FLASH THESE KERNELS OVER THAT I also just flashed it straight off of a new Mikshift install and I got the bootloop until I did this. So if you guys didn't do this, then install bc's kernel and flash Scary kernel again.
Scaryghoul, I have installed your 1.8 suv successfully on Mikshift. This is great news. I knew it would work, but for some reason I just cant get it running on aosp. I will keep you updated on IRC or through this thread, I haven't seen you on today yet.
Click to expand...
Click to collapse
Thanks for clarifying that, I took down the links until we can get this working on several devices.
ozzie1p said:
Tried going strait from BC's still no go.
Sent from my PG06100 using Tapatalk
Click to expand...
Click to collapse
Did you try both of them over bcnice20's 1.5ghz? Not everyone can handle the suv one.
edit: Links back up! I need some testers to try the fix at the top.
Ya, I flashed right over the top of bc's. Ill try these new ones.
Sent from my PG06100 using Tapatalk
Scaryghoul are the reposted links any different than the old kernels you had up the first time? If not, the suv build would boot and run, but after using the phone after awhile for cpu intensive tasks it would lock up and require a battery pull. Im wondering if just a tiny bit more voltage would solve this problem.
On the stable build, it would run a minute or so and always lock up and require a battery pull..
PaulB007 said:
Scaryghoul are the reposted links any different than the old kernels you had up the first time? If not, the suv build would boot and run, but after using the phone after awhile for cpu intensive tasks it would lock up and require a battery pull. Im wondering if just a tiny bit more voltage would solve this problem.
On the stable build, it would run a minute or so and always lock up and require a battery pull..
Click to expand...
Click to collapse
Same links....and I see. If the stable build has the same issue as the suv, then it's not the voltage >.<
Oops. Thought they were new. At least I got the flash bug scratched. Flashed over both bc 1.5 and 1.8, no go.
Sent from my PG06100 using Tapatalk
Scaryghoul said:
Same links....and I see. If the stable build has the same issue as the suv, then it's not the voltage >.<
Click to expand...
Click to collapse
Whats the suspected culprit?
ozzie1p said:
Oops. Thought they were new. At least I got the flash bug scratched. Flashed over both bc 1.5 and 1.8, no go.
Sent from my PG06100 using Tapatalk
Click to expand...
Click to collapse
PaulB007 said:
Whats the suspected culprit?
Click to expand...
Click to collapse
I don't know so much for the freezes, but I believe that the booting has to do with me using my old voltages, and sense handling things differently than aosp >.<
I'll redo the voltage table later.
Just Wondering?
When Source Code is released will you make a suv kernel for the Gingerbread Update i loved it on froyo and mikshift and gave great battery life.
notsointeresting said:
Just Wondering?
When Source Code is released will you make a suv kernel for the Gingerbread Update i loved it on froyo and mikshift and gave great battery life.
Click to expand...
Click to collapse
The source code isn't actually the issue right now. Lack of motivation mainly, I would consider it more if I hadn't deleted my toolchain from my dev station, can't be bothered to get another one setup right now.
When I get motivated again I will, I honestly don't use my phone much anymore(maybe pick it up once or twice a day).
Scaryghoul said:
The source code isn't actually the issue right now. Lack of motivation mainly, I would consider it more if I hadn't deleted my toolchain from my dev station, can't be bothered to get another one setup right now.
When I get motivated again I will, I honestly don't use my phone much anymore(maybe pick it up once or twice a day).
Click to expand...
Click to collapse
Ah ok that sucks was really hoping for it but I understand thanks for the fast reply
Scaryghoul said:
The source code isn't actually the issue right now. Lack of motivation mainly, I would consider it more if I hadn't deleted my toolchain from my dev station, can't be bothered to get another one setup right now.
When I get motivated again I will, I honestly don't use my phone much anymore(maybe pick it up once or twice a day).
Click to expand...
Click to collapse
The ndk from google's web site has the toolchains needed to build gb kernel in it. The dl isn't terribly huge.
Sent from my PG06100 using XDA Premium App
This kernel is based on Thalamus's Oxygen Kernel but with AVS and he's given me permission to post it here for testing.
I implemented AVS from scratch (based on the Code Aurora kernel) and it seems to work well for me.
AVS uses some hardware to emulate the longest gate delays through the CPU datapath. If the delay is longer than expected, the CPU voltage can be decreased, if shorter then it can be increased. This means that the CPU is always running near the minimum voltage it requires and because power consumption rises with the square of voltage this is a good thing.
Here are the results of some initial tests (full load, no idle):
Clock Speed, Without AVS, With AVS
1113600,234mA,223mA
998400,207mA,190mA
768000,158mA,138mA
499200,111mA,93mA
384000,90mA,79mA
245000,70mA,64mA
So there are power savings of about 8-15%
All patches are initially pushed here:
https://github.com/dzo/kernel/tree/2.6.35-bravo-exp
and should end up here:
https://github.com/thalamus/kernel/tree/2.6.35-bravo-exp
You can see the current status of AVS by doing:
Code:
cat /sys/module/avs/parameters/status
Doing:
Code:
echo 1 > /sys/module/avs/parameters/debug
will put lots of debugging info in the kernel log.
To disable AVS do:
Code:
echo 0 > /sys/module/avs/parameters/enabled
The minimum voltage is set to 900mV but you can change this using e.g.:
Code:
echo 850 > /sys/module/avs/parameters/vdd_min
Putting too low a value in here will crash your phone because AVS seems to have trouble with low frequencies.
I also added some extra frequency steps, 76.8MHz and 192MHz.
Don't expect huge power savings, the CPU is only one of the things using power on our devices.
I think AVS is a nice idea and I'd like to know how stable it is on other people's phones.
To install, flash the attached update zip from recovery.
Please don't use this kernel unless you are fairly well informed about what you are doing.
15/4/12: Updated kernel with higher vdd_min
Going to give this a test now, I'll report back later.
How did you produce those mA readings btw?
have you tried using other kernels like Eviolets one? does it really save much more battery than EVs?
is it 100% stable??
with the kernel using some hardware to calculate the voltages needed wouldnt it take some more power to get the calculations done?
cez10 said:
have you tried using other kernels like Eviolets one? does it really save much more battery than EVs?
Click to expand...
Click to collapse
Why don't you try it and find out instead of asking questions.
is it 100% stable??
Click to expand...
Click to collapse
I think the words '[Kernel]Experimental' in the thread title are a clue.
with the kernel using some hardware to calculate the voltages needed wouldnt it take some more power to get the calculations done?
Click to expand...
Click to collapse
The overhead of the calculations is negligible.
So this is only for gingerbread AOSP ROMs or works on Sense as well?
lvnatic said:
So this is only for gingerbread AOSP ROMs or works on Sense as well?
Click to expand...
Click to collapse
Oh my...people just want to be spoonfed on XDA these days.
This kernel is based on Thalamus's Oxygen Kernel
Click to expand...
Click to collapse
As Oxygen is an AOSP ROM it's fairly clear that it's not going to be a sense kernel isn't it?
Thanks for sharing this.
What are the available governors? I can't find this information on github.
Will switching between governors (depending on phone state) cause any issues with the voltage change, that aren't advised?
_thalamus said:
Oh my...people just want to be spoonfed on XDA these days.
As Oxygen is an AOSP ROM it's fairly clear that it's not going to be a sense kernel isn't it?
Click to expand...
Click to collapse
He never mentioned it is specifically for AOSP or Sense ROMs. I was wondering if this is just a separate script, not kernel dependent. But if I give it a 2nd read then yes, it seems indeed it is an entire kernel, my bad, no need for a spoon...or w/e it means.
lvnatic said:
He never mentioned it is specifically for AOSP or Sense ROMs. I was wondering if this is just a separate script, not kernel dependent. But if I give it a 2nd read then yes, it seems indeed it is an entire kernel, my bad, no need for a spoon...or w/e it means.
Click to expand...
Click to collapse
Don't listen to Thalamus. He has no time for people less "knowledgeable" than him. There was a time where I thought a kernel was a kernel.
I thought I had escaped his unhelpful comments when I left Oxygen thanks to his attitude (if you don't like his attitude, then tough is the general gist of it). If he was a shop owner he would go bankrupt, quickly, as he has no people skills whatsoever.
If he wasn't a dev, he would be labeled a troll, yet he is allowed to get away with being nasty to people. When will XDA introduce a -thanks button?
I think the saying goes, if you don't have anything nice to say, then don't say anything at all.
Thanks, this one looks like a good project
As to stability: i've been using this kernel for a couple hours without issues, with very small draining btw; anyway a few minutes ago the phone became unresponsive: i was just typing a message with whatsapp, clocked 192x806, and a freeze occurred. A soft reset did the trick.
Keep up the good job
Edit: i'm on beta 2 fyi...
chronicfathead said:
Don't listen to Thalamus. He has no time for people less "knowledgeable" than him. There was a time where I thought a kernel was a kernel.
I thought I had escaped his unhelpful comments when I left Oxygen thanks to his attitude (if you don't like his attitude, then tough is the general gist of it). If he was a shop owner he would go bankrupt, quickly, as he has no people skills whatsoever.
If he wasn't a dev, he would be labeled a troll, yet he is allowed to get away with being nasty to people. When will XDA introduce a -thanks button?
I think the saying goes, if you don't have anything nice to say, then don't say anything at all.
Click to expand...
Click to collapse
Hahahahahaha.
That cheered me up, I'm having a crap day.
Happy to be of assistance.
Edit: You prove how little you know about me by saying that I have no time for people less knowledgeable than me. That is totally untrue. I spend a lot of time helping people who are less knowledgeable than me. What I have no time for is laziness, people who won't help themselves or idiots. There is a big difference.
_thalamus said:
Hahahahahaha.
That cheered me up, I'm having a crap day.
Happy to be of assistance.
Edit: You prove how little you know about me by saying that I have no time for people less knowledgeable than me. That is totally untrue. I spend a lot of time helping people who are less knowledgeable than me. What I have no time for is laziness, people who won't help themselves or idiots. There is a big difference.
Click to expand...
Click to collapse
I only base my observation on posts of yours that I have read. Rather than shooting people down, advise them so they can improve their knowledge.
sent by touching my Desire
In Airplane mode i had 2mA battery usage all night without AVS and 5mA usage with AVS. This is via Battery monitor widget.
Xinot said:
In Airplane mode i had 2mA battery usage all night without AVS and 5mA usage with AVS. This is via Battery monitor widget.
Click to expand...
Click to collapse
AVS has nothing to do with power consumption while the device is asleep. When the phone sleeps, the CPU is power collapsed, i.e. is completely powered down. AVS only changes the voltage while the CPU is awake.
The Kernel work great on Miui 1.4.8 since 2 days! No reboot or freeze... and in idle with JiuceDefender, 652Mhz max ondemand over 3h the device lost only 2% accu
Thanks for your work
Sent from my HTC Desire using XDA App
I've just updated the kernel in the first post to increase the minimum voltage and remove some possibly unstable frequencies.
Should be more stable now.
dzo said:
AVS has nothing to do with power consumption while the device is asleep. When the phone sleeps, the CPU is power collapsed, i.e. is completely powered down. AVS only changes the voltage while the CPU is awake.
Click to expand...
Click to collapse
OukkiDoukki! So i have something else going on here...
Thanks running sweet keep up the great work using on GV 2.0
Sent from my HTC Desire using XDA Premium App
cez10 said:
have you tried using other kernels like Eviolets one? does it really save much more battery than EVs?
is it 100% stable??
Click to expand...
Click to collapse
Just a quick post to say that I've been testing this kernel for 2/3 days (actually the version that Thalamus has in his experimental github) and find the battery usage to be the same. But the AVS code seems much cleaner than the implementation I have.
As for stability, I haven't had a single crash yet. And overall speed seems better than on my kernel.
Quadrant also confirms this.
Regards,
EViollet said:
Just a quick post to say that I've been testing this kernel for 2/3 days (actually the version that Thalamus has in his experimental github) and find the battery usage to be the same. But the AVS code seems much cleaner than the implementation I have.
As for stability, I haven't had a single crash yet. And overall speed seems better than on my kernel.
Quadrant also confirms this.
Regards,
Click to expand...
Click to collapse
Do you think you will be compiling ManU 1.5 from this source then?
I was browsing the Optimas 2x forum today and ran into an awesome kernel with GPU overclock. which sounds pretty cool to me. also the dev mentioned something about overclocking "system bus" which improvers memory/2D/3D/etc. i think someone in this forum should take a look into this KERNEL and try letting us taste some of this goodness.
Here are the links:
http://forum.xda-developers.com/showthread.php?t=1119771
http://forum.xda-developers.com/showpost.php?p=14654927&postcount=36
while im no genius when it comes to this stuff, somehow i would suspect that people here are already looking into this.
i could be wrong tho lol
pyckvi said:
I was browsing the Optimas 2x forum today and ran into an awesome kernel with GPU overclock. which sounds pretty cool to me. also the dev mentioned something about overclocking "system bus" which improvers memory/2D/3D/etc. i think someone in this forum should take a look into this KERNEL and try letting us taste some of this goodness.
Here are the links:
http://forum.xda-developers.com/showthread.php?t=1119771
http://forum.xda-developers.com/showpost.php?p=14654927&postcount=36
Click to expand...
Click to collapse
The person to ask this to is Morfic. He's all about tweaking bus speeds to improve not only cpu but gpu performance as well. But much of what you've already requested has been incorporated
jlevy73 said:
The person to ask this to is Morfic. He's all about tweaking bus speeds to improve not only cpu but gpu performance as well. But much of what you've already requested has been incorporated
Click to expand...
Click to collapse
But where is he...??
G2X
CPU overclock is something that makes sense for us right now but what would a GPU overclock get us? To me thats just something that will lower the life of our phone with no real reward until games come out that our phone can't run. Right now our phone can run pretty much all games at full speed.
gpu overclocking would be sweet... now my question would be has anyone tried to load Optimas 2x kernel/software on the g2x since they are pretty much the same hardware(in theory you would think it would work)... i might even try to load this kernel onto my phone when i get home from work so if i mess anything up ill have my gear to fix it
crisis187 said:
gpu overclocking would be sweet... now my question would be has anyone tried to load Optimas 2x kernel/software on the g2x since they are pretty much the same hardware(in theory you would think it would work)... i might even try to load this kernel onto my phone when i get home from work so if i mess anything up ill have my gear to fix it
Click to expand...
Click to collapse
Please don't try to load O2x software on your G2x.
pyckvi said:
I was browsing the Optimas 2x forum today and ran into an awesome kernel with GPU overclock. which sounds pretty cool to me. also the dev mentioned something about overclocking "system bus" which improvers memory/2D/3D/etc. i think someone in this forum should take a look into this KERNEL and try letting us taste some of this goodness.
Here are the links:
http://forum.xda-developers.com/showthread.php?t=1119771
http://forum.xda-developers.com/showpost.php?p=14654927&postcount=36
Click to expand...
Click to collapse
I remember reading a while ago that GPU/System bus overclocking was attempted by some kernel dev, then later on, the dev realized through extensive testing that GPU and system bus clocks were locked, the changes to the kernel source had no effect (hardwired). Now this was a few months ago when I was reading up on Tegra kernel development before I got my G2x. Now all these could have been obsolete, and maybe now someone has found a way to do the above via kernel source updates.
Another issue that most people don't mention here and many people have been guilty of, is the GPL issue. The guy who supposedly did this overclocking has not published his kernel source code anywhere (GPL/XDA rules issues), so no one can examine what he did and prove that it worked....
GideonX said:
Please don't try to load O2x software on your G2x.
Click to expand...
Click to collapse
have you tried it yet though is my question
im not worried if i flash a kernel and it doesnt work i can reflash my old kernel if it doesnt work and gets stuck into a bootloop
crisis187 said:
have you tried it yet though is my question
Click to expand...
Click to collapse
Someone in another thread tried this and it messed up their baseband. A restore doesn't fix it apparently.
Big rush dog, the tiamat kernel guru and Guy getting engadet headlines for oc the xoom to 1.7 ghz has gpu oc in his kernels. I will be honest though, I can't tell the difference except maybe video streaming works a little smoother. I personally don't think it is worth the devs time...
Sent from my LG-P999 using XDA App
Howdy! I'm the developer of that kernel
To be honest the GPU overclocks aren't all that beneficial. There is a little bit of a speed bump (I managed to get the highest score on nenamark2 for example). But the difference is was 27fps vs 32fps. If someone is interested in incorporating that into the g2x I'll be happy to show them the changes I've made. I haven't released the source because I'm lazy but there isn't too much to it.
Actually, if you look at the voltKernel sources for the O2X you'll see the same changes there.
chuckhriczko said:
CPU overclock is something that makes sense for us right now but what would a GPU overclock get us? To me thats just something that will lower the life of our phone with no real reward until games come out that our phone can't run. Right now our phone can run pretty much all games at full speed.
Click to expand...
Click to collapse
Yes, superficial benchmarks like quadrant can be pushed to 5400 only with max cpu oc.
However, did you notice how 1.2 thru 1.5 gets you the same fps with no added benefit than more heat created?
Pushing other things other than cpu should let us remove bottlenecks and not tighten them up.
If you want your G2x to life 20yrs, 1.5ghz is not the way to go.
I have no kernel ready for release, to notice changes, I stuck to 1.5ghz, but the final result will be more likely 1.2 or 1.3ghz.
Maybe with a "don't hold my hand, give me freedom or give me death" DBU version at 1.5Ghz later.
I'm not shy to increase vcore on a SoC. But unlike the Nexus S, this thing gets HOT, fast.
Avetny pointed out that thread, I'll see if fallout hit something I have missed so far.
The clocks get compared to chip defaults in many places, choosing the smaller of the two, so it's just tedious replacing them with sane defaults, unless I stick to my current approach of offsets instead of absolutes.
We'll see.
That's also the reason I don't update my kernel often. Right now commits in cm git are only preparatory, config changes that made things smoother I already used.
I'll release something if they finish their version of BLN.
Or if I'm happy with gpu/bus/ram oc/tweaks.
not going to make people flash a kernel for no reason. As jlevy can attest, kernel not following cm git, not even based on it can work very well.
Not having latest cm commit on kernels that take another approach is not always useful.
Especially if we track regressions that cm devs back out later, that's all this gains.
So yes, there will be a gpu oc, when it's ready.
Great!
@ fallout0 thank you i hope that you can help out one of our devs on this.
morfic said:
Yes, superficial benchmarks like quadrant can be pushed to 5400 only with max cpu oc.
However, did you notice how 1.2 thru 1.5 gets you the same fps with no added benefit than more heat created?
Pushing other things other than cpu should let us remove bottlenecks and not tighten them up.
If you want your G2x to life 20yrs, 1.5ghz is not the way to go.
I have no kernel ready for release, to notice changes, I stuck to 1.5ghz, but the final result will be more likely 1.2 or 1.3ghz.
Maybe with a "don't hold my hand, give me freedom or give me death" DBU version at 1.5Ghz later.
I'm not shy to increase vcore on a SoC. But unlike the Nexus S, this thing gets HOT, fast.
Avetny pointed out that thread, I'll see if fallout hit something I have missed so far.
The clocks get compared to chip defaults in many places, choosing the smaller of the two, so it's just tedious replacing them with sane defaults, unless I stick to my current approach of offsets instead of absolutes.
We'll see.
That's also the reason I don't update my kernel often. Right now commits in cm git are only preparatory, config changes that made things smoother I already used.
I'll release something if they finish their version of BLN.
Or if I'm happy with gpu/bus/ram oc/tweaks.
not going to make people flash a kernel for no reason. As jlevy can attest, kernel not following cm git, not even based on it can work very well.
Not having latest cm commit on kernels that take another approach is not always useful.
Especially if we track regressions that cm devs back out later, that's all this gains.
So yes, there will be a gpu oc, when it's ready.
Click to expand...
Click to collapse
thanks morfic i hope everything goes smooth with your kernel, i would love to test it out once u feel it is ready. and thanks for not rushing it.
faux123 said:
I remember reading a while ago that GPU/System bus overclocking was attempted by some kernel dev, then later on, the dev realized through extensive testing that GPU and system bus clocks were locked, the changes to the kernel source had no effect (hardwired). Now this was a few months ago when I was reading up on Tegra kernel development before I got my G2x. Now all these could have been obsolete, and maybe now someone has found a way to do the above via kernel source updates.
Another issue that most people don't mention here and many people have been guilty of, is the GPL issue. The guy who supposedly did this overclocking has not published his kernel source code anywhere (GPL/XDA rules issues), so no one can examine what he did and prove that it worked....
Click to expand...
Click to collapse
You should talk to Fallout0 he seems like he got past the system bus/GPU locked issue. both of you can maybe learn something new from each other. & it would be awesome if the both of you can work on a kernel together.
Wouldn't a higher clocked G2x cause more heat? Heat being the reason this things reboots so often? Maybe a slower G2x is the way to go.
Would overclocking the gpu help run nds4droid any better? What else would ocing the gpu do? Everything seems to be very fast as it is lol
Sent from my LG-P999 using XDA Premium App
dkb218 said:
Wouldn't a higher clocked G2x cause more heat? Heat being the reason this things reboots so often? Maybe a slower G2x is the way to go.
Click to expand...
Click to collapse
Pushing cpu more I don't see useful other than keep up with your buddy's Nexus S' quadrant scores and make sure your hands stay warm in a cold Chicago winter.
I build kernels usually when things stutter or otherwise annoy me. The pushing the OC usually comes by request of those who just want more more more.
I do like to remove bottle necks.
The hardwired clocks. Well the.cpu ones are hardwired too.
The gpu/bus oc works, until boost and throttling kick in, where again values are compared to hardwired values. using offsets after the comparison would be the way around without killing boosting and throttling.
Guess main thing that stopped me is the heat at 1.5ghz, and the frowns over 1.2ghz and 1.3ghz kernels, without further "what else is in there"
Still hoping fallout can share what he/she has, it'll help making this a reality, sooner.
It's tedious. Most of all.