Related
Over at PROJ: Overclocking the Adreno GPU on Snapdragon Devices they were trying to achieve to overclock the GPU to improve performance.
I've decided to open this thread for dedication for software porting/improving for adreno GPU on all Snapdragon chips.
1st thing we require/need to start work is:
Any source for the adreno/gpu drivers that are currently being run on our devices.
Its been mentioned that Acer liquid has same gpu running on lower cpu clock and achieving greater results.
Open source 3D driver for Snapdragon @ CodeAurora | Site Source
Acer liquid GPU drivers and source
Require Acer Liquid dump of adreno libegl files
Acer Liquid Kernel Source | Source site
AdamG working on this repo
http://github.com/xdabravoteam/cm-kernel
(May or may not be helpful)
glbenchmark: Acer liquid | Nexus One = Desire | EVO4G | Incredible
From there we should be able to improve our drivers from other devices but i think its a good start to look at the Acer Liquid since the source is available iirc.
That should be what we need for a start.
If i'm missing anything please let me know and i'll add it.
For reference to the other threads i posted.
Desire Porting thread | EVO4G porting thread | Incredible porting Thread
Hopefully we can get this project going and improve our GPU performance.
reserved for changelog
reserved for downloads/links
Alright, I'm going to write out everything I know so far in the best of my knowledge to help with others who are looking at this project. Conjecture will be separated off as thoroughly as possible. Let me know if any of this is wrong or needs updating, it's to be informative as possible.
Acer Liquid E:
There is a kernel framework that activates the GPU and provides clock and power control. Changing these states seems to be interrupt driven, upon the right signal the clock will be shuffled through a few states depending on load. The clock is always set through the minimum clock rate and the maximum clock rate is inflexible.
Outside of this, there is a non kernel-level driver binary that controls all other GPU operations. We do not yet know where it is or how it operates in the boot process.
Known points of interest:
Liquid E roms, to find the GPU binary driver portion.
Kernel source/drivers/char/msm_kgsl for the kernel portion of the driver.*
kernel source/arch/arm/msm/
Nexus One:
There too is also a kernel framework. It does not appear to initialize the driver at any point. In fact, I cannot find any external calls to the kgsl code whatsoever. They are most likely called from the binary portion of the driver, whose whereabouts are also a mystery.
Known points of interest:
kernel source/drivers/video/msm/ and msm/kgsl
kernel source/arch/arm/msm/
Conjecture:
My personal belief is that the radio plays a role in the Nexus One's GPU control system. It is the only part I know of initialized early enough to get us a framebuffer that isn't the kernel. The GPU may still be initialized in some part of the kernel I have not charted, but I have yet to see anything. Those whom I've contacted on this issue have not responded.
On a related note, there could also be a security system in the radio (or even the GPU firmware itself) that prevents kernel access to specific functions and further prevents user access to specific functions. If it exists and if it's a problem, we may have to find a way to maneuver around it.
The Acer E's binary driver really should be in the main part of any packaged rom. Upgrading it would be too useful to lock off somewhere.
Questions to answer so far:
How does the GPU get initialized in both devices?
Where in the process does this happen?
What is done during this time? (control handed off, some lockdown event, clocks set, etc...)
Is there a security mechanism that is set differently on the Liquid E?
If so, can it be defeated?
Where is the binary part of the driver for both devices?
Expected gains
The Acer Liquid E benches ~50% better (in nenamark at least) than the Nexus One. If we can get their driver implemented on our devices, we should get similar gains in OpenGL ES 2.0. OGL 1.1 (and 2D if implemented differently) performance gains may differ.
Anyways, I'll try as best as I can to help out anyone who is trying this undertaking while at the same time trying to avoid riling up everyone as bad on the radio subject as I did in the other thread. Also, I'm running this all from memory, so everything may not be spot on.
* If needed, I can chart out the functions to create a pleasant flow chart for people new to this area to follow.
EDIT: Oi, there's something really wacky about my formatting, only certain parts actually look really bolded. It's like my fonts shrink slightly after the Acer Liquid E list. Hope no one has bad OCD like I do.
EDIT 2: Updated with Jack_R1's correction below.
nothing to add here but my support
best of luck gentlemen, I believe this is definitely needed.
About time such a thread got started!I was tracking the thread about overclocking closely,but things got a little too intense there...
So,because I was in the UK for vacation this past week(call me an idiot,I'll accept it) and just got back in Greece I have some questions.First,wasn't intersectraven working on a kernel with the E's driver built in?How is that going?And second,would it be of any benefit trying to port the driver bit by bit?I mean,we could port one "piece" of it at a time and see where in the process things get nasty.
Thanks!
storm99999 said:
The Acer Liquid E benches ~50% better (in nenamark at least) than the Nexus One. The CPU on the E is clocked at 75% or so of the N1. There is a known relationship between the CPU and GPU clocks, so assuming it's perfectly linear, it is possible that the new GPU code would be 75% faster in OpenGL ES 2.0 code. Gains may be different in other OGL versions.
Click to expand...
Click to collapse
Have to correct this. The relationship of GPU clock to CPU isn't a given number, relationship to other places is. The GPU frequency is the same in Liquid E and in Nexus, so the gain will be 50%. Still, a lot to gain, if possible.
It's only semantics, but in case the porting succeeds - it's good to know the ballpark for the expected gains.
Best of luck with this effort, I hope it'll succeed.
tolis626 said:
And second,would it be of any benefit trying to port the driver bit by bit?I mean,we could port one "piece" of it at a time and see where in the process things get nasty.
Thanks!
Click to expand...
Click to collapse
We couldn't do it bit by bit, as it's an all or nothing deal, everything must be in place before the code works, but that did give me an interesting thought...
You see, iR did port the driver over, but it crashed on boot. There's two reasons for this, either it couldn't find a userspace driver and we're much closer than we think, or it went about the wrong way. We know that the driver can be ported without compilation errors based on this, so... I wonder if we can port both drivers at the same time? Give the framework for the current GPU driver to work so that it doesn't crash, but have the new driver reporting errors? It would at least show us a bit more about the boot process.
Say we had all of the new driver and all of the old. Only the new driver is "active" but the old driver has all of its symbols as they were. Any external program calling these symbols would get them, but they'd never be activated by the kernel. Even better, we could redirect the symbols to the CodeAurora equivalents. Then we could map what is actually called early on and possibly by whom.
It's a bit absurd, but it's a possibility going forward. Now if only we had some way of getting kernel panic dumps off of iR's kernel, then we could make some real progress.
Anyways, my big post updated to reflect Jack_R1's correction.
storm99999 said:
We couldn't do it bit by bit, as it's an all or nothing deal, everything must be in place before the code works, but that did give me an interesting thought...
You see, iR did port the driver over, but it crashed on boot. There's two reasons for this, either it couldn't find a userspace driver and we're much closer than we think, or it went about the wrong way. We know that the driver can be ported without compilation errors based on this, so... I wonder if we can port both drivers at the same time? Give the framework for the current GPU driver to work so that it doesn't crash, but have the new driver reporting errors? It would at least show us a bit more about the boot process.
Say we had all of the new driver and all of the old. Only the new driver is "active" but the old driver has all of its symbols as they were. Any external program calling these symbols would get them, but they'd never be activated by the kernel. Even better, we could redirect the symbols to the CodeAurora equivalents. Then we could map what is actually called early on and possibly by whom.
It's a bit absurd, but it's a possibility going forward. Now if only we had some way of getting kernel panic dumps off of iR's kernel, then we could make some real progress.
Anyways, my big post updated to reflect Jack_R1's correction.
Click to expand...
Click to collapse
This idea seems plausible, i'll pm iR if hes able to do that
If anyone reading this is also able to do this please let us know. I'm sure theres many people who are willing to test this.
i think that you should share this tread to desire and evo, and maybe get some more help from theirs devs. its basically what we all want
madman_cro said:
i think that you should share this tread to desire and evo, and maybe get some more help from theirs devs. its basically what we all want
Click to expand...
Click to collapse
That's right.Evo,Desire,Incredible,they all use the same GPU.I too believe we could cooperate with devs from these forums.
This brings back memories...
I'll keep an eye on this. Good job babijoee.
NeoS2007 said:
This brings back memories...
I'll keep an eye on this. Good job babijoee.
Click to expand...
Click to collapse
good memmories from wm))
tolis626 said:
That's right.Evo,Desire,Incredible,they all use the same GPU.I too believe we could cooperate with devs from these forums.
Click to expand...
Click to collapse
Will do lets all work together
NeoS2007 said:
This brings back memories...
I'll keep an eye on this. Good job babijoee.
Click to expand...
Click to collapse
like you i want to improve graphics on our beloved devices.
Edit:
I've setup a duplicate thread in Desire,Incredible and Evo threads all linking back to this main one. Alot of people are thinking the way to improve GPU is only to OC it and NeoS2007 and myself know better. We both were involved in winmo msm7k gpu software/driver improvement and achieved great results with the help of other xda members/developers.
Not for one second did i believe that our devices were running optimised graphic drivers and other devices such as Acer liquid E for example proves that.
Posted in the Evo section as well. Told some idiots to stay back
I think one thing that we had an issue with before was the fact that it wasn't integrated in the full Qualcomm kernel. There could have been other code in there it depended on that we didn't pull. We need to clone the whole CodeAurora kernel repo (.32) and build it and see if it boots.
Then there's the Liquid E stuff. And the new FroYo Sense kernel is a .32, so once we get HTC's source it may be able to be implemented there too. I don't think any of the Nexus kernels that are around are .32 so that could be why it wouldn't build.
Just my $.02
<Postedit> I hope you guys don't mind me detailing out all of what I've done with hopes that someone will find it helpful, it's very... verbose. Plus, if I have to share the source, I can remember exactly what files were tweaked to send a smaller than 700Mb file.
Alright, here's my current plan once I get my build environment stable again (oh hey, Ubuntu 10.10? Do it!):
The N1 code has two layers, a wrapper layer and the interface layer. The Liquid E code has only an interface layer which appears compatible to (but different than) the wrapper layer on the N1. I'm going to replace the N1's interface layer to see if it still runs. If it does, we now will have a current kernel build that would allow both drivers to operate, barring complications.
The current driver would have all the wrapper layer code it needs, but the new driver will have the correct interface layer code it needs.
Then, I'll bust open a Liquid E rom (Aren't the Liquid and Liquid E roms interchangeable? That worries me.), hunt down the driver, find out how it starts up in the system, add it to a current rom, test it for differences, and then break the interface layer by putting no-op asm.
This is all simplified (and possibly horribly wrong) of course, but anyone looking at this project may be interested in trying something similar.
Edit: Alright, I found out that both of them have an on-boot frame buffer, but the new Qualcomm one is much larger and more capable. I'll start my porting project there, as that quite literally could be the difference.
Edit2: Oh god the Kconfig errors! They've overtaken the ramparts!
Edit3: It looks like I'm missing a large series of .h files, but other than that, there have been no compilation errors. Also, if you end up where I am, you want MDP31 instead of MDP40, kinda caught me off guard.
Edit4: I like keeping things written down for everyone. Anyways, here's the list of file movements I've done so far for anyone interested, as I need to make sure that if I get a result, it must be duplicatable.
Acer Kernel linux/include/msm_mdp.h must be moved to the same place in a Cyan kernel.
All of Acer Kernel's drivers/video/msm/ must be copied over but the kgsl folder must stay intact.
A blank Kconfig must be made in the same folder.
The Acer Kernel's drivers/video/Kconfig must be copied over. The options you want:
We have a MDP31 chip
Not sure yet, but autodetecting the panel is what I've chosen
MDDP 2.0 doesn't seem to matter, so best left disabled.
After all of this, there seems to be missing a single .h file, which has the function dma_cache_pre_ops() and related in it.
Edit5: I really hope that putting this much detail out doesn't bother anyone... Anyways, the next step fixed most of this, I modified msm_fb.c to have this in the definitions:
Code:
#define pgprot_noncached(prot) \
__pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_UNCACHED)
#define pgprot_writecombine(prot) \
__pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_BUFFERABLE)
#define pgprot_device(prot) \
__pgprot_modify(prot, L_PTE_MT_MASK|L_PTE_EXEC, L_PTE_MT_DEV_NONSHARED)
#define pgprot_writethroughcache(prot) \
__pgprot((pgprot_val(prot) & ~L_PTE_MT_MASK) | L_PTE_MT_WRITETHROUGH)
#define pgprot_writebackcache(prot) \
__pgprot((pgprot_val(prot) & ~L_PTE_MT_MASK) | L_PTE_MT_WRITEBACK)
#define pgprot_writebackwacache(prot) \
__pgprot((pgprot_val(prot) & ~L_PTE_MT_MASK) | L_PTE_MT_WRITEALLOC)
This does throw some errors cause this isn't supposed to be there, but this is just a temporary hack.
The dma problem disappeared after that (don't know why...) and now I just have to find out why "info" is undefined at line 840 now.
Edit6: It looks like disabling the boot logo (as dumb as that is) gets rid of that error, but it throws a warning that the system needs the logo to be enabled. It's just a temporary measure, plus, I'd love to see a logo-less boot screen.
Edit7: Added a NULL to line 104 in drivers/video/msm/msm_fb_bl.c before
Geniusdog254 said:
Posted in the Evo section as well. Told some idiots to stay back
I think one thing that we had an issue with before was the fact that it wasn't integrated in the full Qualcomm kernel. There could have been other code in there it depended on that we didn't pull. We need to clone the whole CodeAurora kernel repo (.32) and build it and see if it boots.
Then there's the Liquid E stuff. And the new FroYo Sense kernel is a .32, so once we get HTC's source it may be able to be implemented there too. I don't think any of the Nexus kernels that are around are .32 so that could be why it wouldn't build.
Just my $.02
Click to expand...
Click to collapse
I have been using http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/drivers/staging/msm/mdp.c as a base reference for my work and for bugfixes, as the staging area has the driver implemented as a .35. I'm going to try something, maybe downloading the whole source from this one repo and using the config I got, maybe it will spare me the issue. It's so clean, so error free, I'm liking it.
Edit9: Alright, downloaded 2.6.35 kernel, copy-pasted staging driver, got rid of all the errors prior.
Wow great start storm it sound like you achieved quite alot in write short time frame. Keep it up. Need any testing? Let any of us know
babijoee said:
Wow great start storm it sound like you achieved quite alot in write short time frame. Keep it up. Need any testing? Let any of us know
Click to expand...
Click to collapse
Oi... I'm far away from testing here, my current goal is just to switch framebuffers... I realized where I'm going wrong, so I'm rebasing to iR's kernel source. It's a .35 source and that's been where all of my problems have been.
Quite literally, here's my procedure as of now: Get the Kconfig for drivers/video from the Acer Liquid E driver, copy and paste the framebuffer code from drivers/staging/msm to drivers/video/msm, try to compile.
I'll keep this post updated once I get the iR source downloaded.
Edit1: Alright, got my compiling to work, so far the only tweak I need to do is add "#include <linux/android_pmem.h>" to msm_fb.c (edit3: instead, put in msm_fb.h) , still having errors in GPIO...
Edit2: Added definition list from mach/proc_comm.h to staging-devices.c and mdp_vsync.c, repeated adding NULL as above in edit7.
Edit4: Changed line 23 in mdp_ppp.c to #include "msm_mdp.h"
Edit5: Commented out line 71 and 72 in mddi.c
Edit6: replaced dma_coherent_pre_ops and post_ops with dmb, as the functions prior don't exist and a commit says dmb replaces them. Really not sure about this. Compiling is smooth sailing from hereon out, except a duplicated function. Let's see if it kills my phone.
I have read through this and can say I honestly have no idea what half of the mumbo jumbo means but ill give it a bump and good luck to all you devs.
Sent from my Nexus One using XDA App
storm99999 said:
Oi... I'm far away from testing here, my current goal is just to switch framebuffers... I realized where I'm going wrong, so I'm rebasing to iR's kernel source. It's a .35 source and that's been where all of my problems have been.
Quite literally, here's my procedure as of now: Get the Kconfig for drivers/video from the Acer Liquid E driver, copy and paste the framebuffer code from drivers/staging/msm to drivers/video/msm, try to compile.
I'll keep this post updated once I get the iR source downloaded.
Edit1: Alright, got my compiling to work, so far the only tweak I need to do is add "#include <linux/android_pmem.h>" to msm_fb.c (edit3: instead, put in msm_fb.h) , still having errors in GPIO...
Edit2: Added definition list from mach/proc_comm.h to staging-devices.c and mdp_vsync.c, repeated adding NULL as above in edit7.
Edit4: Changed line 23 in mdp_ppp.c to #include "msm_mdp.h"
Edit5: Commented out line 71 and 72 in mddi.c
Click to expand...
Click to collapse
Ah k thanks for the update.
Hello,
My goal is to compile rowboat ( froyo) for the NC.
To start, I'm trying to compile u-boot for NC with the sources provided by B&N with no luck
I tried with omap3621_boxer_config with no luck. I had some errors at compilation.
Once fixed ( with few hacks) I've got a small u-boot.bin (about) 160Kb whereas stock u-boot is 280 kb.
What' wrong ? I think the sources don't match the NC binaries.
Occip
Try omap3621_evt2_config.
pokey9000 said:
Try omap3621_evt2_config.
Click to expand...
Click to collapse
I don't find this config in u-boot .
There are only
omap3621_boxer
omap3621_edp1
omap3621zoom3
Did you successfully compile u-boot with the sources ?
Occip
Look at the makefile, not the headers.
Rowboat Wiki http://code.google.com/p/rowboat/ misses completely OMAP36xx chips out of its builds for some reason (Motorola took them?).
In other words, building for OMAP35xx may cause some problems/performance issues.
Sure I can be completely wrong, just disregard this.
----------------
fineoils.blogspot.com
"NooKColor: Next Step"
Any reason you're going rowboat rather than http://omappedia.org/wiki/Android_source_code_versions?
As I posted elsewhere, my brain was faulty earlier, the correct target is omap3621_evt1a_defconfig for the kernel, omap3621_evt1a_config for u-boot and x-loader.
For fun, in the kernel I tried faking out the 3621 detection so it believes it's a 3630. Someone earlier (I can't remember) noticed that Nooter was showing bogomips in like with 1GHz, and since I built it for a 3630 target I was hoping the same would apply here. It looks like the top 2 power states are ignored with the 3621, while the 3630 gets all 5.
I get 7.598 MFLOPS in Linpack with this change vs 6.133 with the old; and 1094 in Quadrant vs. 981 with the old. The downsides are that the core gets cranked up to 1.35V vs. 1.26V at 800MHz, and my touchscreen got a lot less responsive. The former is probably not a big deal since most of the time the CPU is not running full out.
The patch:
Code:
diff -Naur arch/arm/mach-omap2/board-3621_evt1a.c ../dev/kernel/arch/arm/mach-omap2/board-3621_evt1a.c
--- arch/arm/mach-omap2/board-3621_evt1a.c 2010-11-25 14:49:49.000000000 -0600
+++ ../dev/kernel/arch/arm/mach-omap2/board-3621_evt1a.c 2010-12-05 20:45:28.537597020 -0600
@@ -624,20 +622,20 @@
{
#if defined(CONFIG_MACH_OMAP3621_EVT1A) && defined (CONFIG_MACH_SDRAM_HYNIX_H8MBX00U0MER0EM_OR_SAMSUNG_K4X4G303PB)
omap2_init_common_hw( h8mbx00u0mer0em_K4X4G303PB_sdrc_params ,
- omap3621_mpu_rate_table,
- omap3621_dsp_rate_table,
- omap3621_l3_rate_table);
+ omap3630_mpu_rate_table,
+ omap3630_dsp_rate_table,
+ omap3630_l3_rate_table);
#elif defined(CONFIG_MACH_OMAP3621_EVT1A) && defined(CONFIG_MACH_SDRAM_HYNIX_H8MBX00U0MER0EM)
omap2_init_common_hw( h8mbx00u0mer0em_sdrc_params ,
- omap3621_mpu_rate_table,
- omap3621_dsp_rate_table,
- omap3621_l3_rate_table);
+ omap3630_mpu_rate_table,
+ omap3630_dsp_rate_table,
+ omap3630_l3_rate_table);
#elif defined(CONFIG_MACH_OMAP3621_EVT1A) && defined (CONFIG_MACH_SDRAM_SAMSUNG_K4X4G303PB)
omap2_init_common_hw( samsung_k4x4g303pb_sdrc_params,
- omap3621_mpu_rate_table,
- omap3621_dsp_rate_table,
- omap3621_l3_rate_table);
+ omap3630_mpu_rate_table,
+ omap3630_dsp_rate_table,
+ omap3630_l3_rate_table);
#endif
omap_init_irq();
omap_gpio_init();
diff -Naur arch/arm/plat-omap/include/mach/cpu.h ../dev/kernel/arch/arm/plat-omap/include/mach/cpu.h
--- arch/arm/plat-omap/include/mach/cpu.h 2010-11-25 14:49:49.000000000 -0600
+++ ../dev/kernel/arch/arm/plat-omap/include/mach/cpu.h 2010-12-05 21:10:15.878587990 -0600
@@ -221,7 +221,8 @@
# endif
#endif
-#if defined(CONFIG_MACH_OMAP3621_BOXER) || defined (CONFIG_MACH_OMAP3621_EVT1A) || defined(CONFIG_MACH_OMAP_3621_EDP)
+//#if defined(CONFIG_MACH_OMAP3621_BOXER) || defined (CONFIG_MACH_OMAP3621_EVT1A) || defined(CONFIG_MACH_OMAP_3621_EDP)
+#if defined(CONFIG_MACH_OMAP3621_BOXER) || defined(CONFIG_MACH_OMAP_3621_EDP)
# undef cpu_is_omap3621
# define cpu_is_omap3621() 1
#endif
Thanks !
Thanks to pokey9000!
It's ok for the evt1 config.
For fun, in the kernel I tried faking out the 3621 detection so it believes it's a 3630. Someone earlier (I can't remember) noticed that Nooter was showing bogomips in like with 1GHz,
Click to expand...
Click to collapse
It was me
I remember that with my igep020 (omap3430) a simple mw command within u-boot could set the frequency of the MPU (and not overrided by the kernel).
After some digs in the kernel, it seems the BT could be enabled easily.
Cheers Occip
occip said:
I remember that with my igep020 (omap3430) a simple mw command within u-boot could set the frequency of the MPU (and not overrided by the kernel).
Click to expand...
Click to collapse
I couldn't make heads or tails of the clock tree code in u-boot and decided to go for broke turning off the 3621 specific code. I still don't know about the touchscreen thing, but I realized that I was comparing the stock kernel against this one. I've rebuilt the kernel from BN's code as provided and will see if the touchscreen is still wonky when I get home.
occip said:
After some digs in the kernel, it seems the BT could be enabled easily.
Click to expand...
Click to collapse
I tried uncommenting the code surrounded by CONFIG_WL127X_RFKILL, and fixing up the GPIO to the one defined right above it, and I get a driver segfault on boot. I guess for starters it makes more sense just to force it on in u-boot.
This page may be helpful.
ft
Overclocking and undervolting
Hi,
I manage to tweak few parameters with the help of pokey9000 code. Now 5 levels are enabled (OPP1 --> OPP5 , 300,600,800,1000,1100 Mhz). it runs pretty fast (same score as droid X in quadrant benchmark). I also tweaked the voltage at every level. At 600Mhz , the MPU has a voltage of 0.850 v (1.1v instead, 30 % decrease), I will check for increased autonomy.
So my omap 3621 seems to be a good production batch item.
Now direction to kernel 2.6.32 with droidX kernel sources (mapphone_defconfig)...
Cheers
Occip
Very good news...
Thanks Occip
occip said:
I manage to tweak few parameters with the help of pokey9000 code. Now 5 levels are enabled (OPP1 --> OPP5 , 300,600,800,1000,1100 Mhz). it runs pretty fast (same score as droid X in quadrant benchmark). I also tweaked the voltage at every level. At 600Mhz , the MPU has a voltage of 0.850 v (1.1v instead, 30 % decrease), I will check for increased autonomy
Click to expand...
Click to collapse
Nice! Did you work around the check for the OPP5 fuse? It's not fused on my NC's OMAP, and when I ignore it to get 1.2G it falls over. I didn't make any changes to the OPP freq/voltage settings though.
pokey9000 said:
Nice! Did you work around the check for the OPP5 fuse? It's not fused on my NC's OMAP, and when I ignore it to get 1.2G it falls over. I didn't make any changes to the OPP freq/voltage settings though.
Click to expand...
Click to collapse
I made an ugly hack the function omap_pm_get_max_vdd1_opp() returns always VDD1_OPP5
I didn't make any tests with frequency higher than 1.1Ghz so ... maybe 1.2Ghz is possible
Amazing work, Pokey and Occip. Are either of you still having screen issues at higher clock speeds?
Sent from my ADR6300 using XDA App
FrasierCrane said:
Amazing work, Pokey and Occip. Are either of you still having screen issues at higher clock speeds?
Click to expand...
Click to collapse
I think the artifacting I saw was a combination of my imagination and a hacked up .apk of Angry Birds. There is still a small issue where the touch screen loses some responsiveness right after the kernel is booted, but clears up after you put the NC to sleep and wake it up again.
Hot damn this is exciting. As the kernel work progresses, will this be something we can add to the NC without recovery, or will we have to wait on this?
Hey,
You can come join us at irc.freenode.net #nookie we have 2.2.1 booting with wifi. Working on the battery.
pokey9000 said:
I think the artifacting I saw was a combination of my imagination and a hacked up .apk of Angry Birds. There is still a small issue where the touch screen loses some responsiveness right after the kernel is booted, but clears up after you put the NC to sleep and wake it up again.
Click to expand...
Click to collapse
Good to hear. The default screen calibration seems a bit conservative for a full-function tablet anyway, so I can definitely see where you're coming from.
Sent from my ADR6300 using XDA App
rhcp0112345 said:
Hey,
You can come join us at irc.freenode.net #nookie we have 2.2.1 booting with wifi. Working on the battery.
Click to expand...
Click to collapse
i would love to be a fly on the wall, but being at work prohibits that. But saying you have 2.2.1 booting.. you mean you have a quasi working cutom froyo build going? double exciting!
Can someone port this kernek to ATT?
http://forum.xda-developers.com/showthread.php?t=1263838
tassadar898 said:
Can someone port this kernek to ATT?
http://forum.xda-developers.com/showthread.php?t=1263838
Click to expand...
Click to collapse
Its possible, but there are differences in the softkeys, charging hardware, and nfc at the minimum, so it will take a little work to port that over entirely. What would be better is for one of our current kernel modders to add some of the features of the SIYAH kernel over to their own.
I plan on pulling in 100 MHz support.
He doesn't have that much more, other than extremely experimental features that if you read the thread, tend to break.
Gokhan is quite talented, but he's also VERY aggressive - if you're more careful, you don't have to go through long beta periods with lots of broken releases like he does.
He also released source code for older kernels as megapatches, and now releases as straight full-source tarball drops. It makes separating the good from the bad EXTREMELY difficult.
As far as features he has that I don't currently:
1) 100 MHz support - I plan on this one, it's a fairly high priority as part of my current power management research
2) Crazy wacky alternative governors - these are a great way to somehow combine lag and poor battery life all in one
3) Charge current control - not possible on our devices, we have a different (very crippled) charger IC
4) Touchscreen stuff - I have seen no reports of people having touchscreen issues. If it ain't broke don't fix it.
5) BLN - I'm on the fence on this one. I think the I777 community may actually have the maturity to handle this one. (BLN's dirty little secret on the I9100/I777 - it holds a wakelock while the light is on. This means you lose 50% battery overnight instead of <10% if a notificiation comes in right after bed.)
Entropy512 said:
5) BLN - I'm on the fence on this one. I think the I777 community may actually have the maturity to handle this one. (BLN's dirty little secret on the I9100/I777 - it holds a wakelock while the light is on. This means you lose 50% battery overnight instead of <10% if a notificiation comes in right after bed.)
Click to expand...
Click to collapse
Would it be possible to get past the wakelock issue if you could program that the BLN shuts off after, say 30min, or user defined? That would work in my case but not sure if everyone universally would like it that way. Just a thought...
Hey Entropy nice to see you here! In siyah you can control the GPU voltage for undervolting. I currently do it using the Tegrak kernel module and I reduced the minimum step of 160 mhz to 750mv down from 950mv. I've noticed a nice bump in battery life. In his 2.1 beta version he also has this available feature
SiyahKernel v2.1 - not released yet -
Time to break some records... both performance-wise and battery-wise...
Overclocking part is optimized and bus frequency selection is modified.
User customizable frequency levels. you still have 8 steps, but you will be able to customize them. wanna change 100 to 150 as 100MHz is not stable on your device? wanna change 1400 to 1304 and 1600 to 1504? or increase 1600 to 1696?
User customizable bus frequency selection. no more overheating. if you are a battery freak, just set it to minimum and your device will last more than ever.
Based on Update3 sources...
Thanks for developing for us!!
I'll look into GPU voltage control once I finish my current power management adventures.
Custom frequency steps seems like asking for stability problems. There's no way this is getting ported until he releases 2.1 final, since he isn't very good about GPL compliance.
Thanks! I look forward to testing. If you need a guinea pig let me know.
Entropy512 said:
I'll look into GPU voltage control once I finish my current power management adventures.
Custom frequency steps seems like asking for stability problems. There's no way this is getting ported until he releases 2.1 final, since he isn't very good about GPL compliance.
Click to expand...
Click to collapse
GPU voltage doesn't bring that much other than stabilizing 400MHz, undervolting doesn't go that far down from stock voltages, unless you underclock heavily too.
Also get off his horse about GPL . The license states that you've got 90 days to release your code, until now he released it within the day for final versions, and betas are no longer released on XDA to get off that technicality of the 5 day rule.
There's enough kernels out there with the "stable" philosophy, some of which barely differentiate from stick sources, so people can go and use those if they want to. Siyah is more a Swiss army knife, but you'll have to be careful not to cut yourself, and it's more fun for some to tinker with the phone.
Edit: What you should port though, is update3 sources, those bring significant upgrades in battery life, speed and sound quality.
AndreiLux said:
GPU voltage doesn't bring that much other than stabilizing 400MHz, undervolting doesn't go that far down from stock voltages, unless you underclock heavily too.
Click to expand...
Click to collapse
Yeah, I figured as much, which is why it's pretty low on my priorities list
Also get off his horse about GPL . The license states that you've got 90 days to release your code, until now he released it within the day for final versions, and betas are no longer released on XDA to get off that technicality of the 5 day rule.
Click to expand...
Click to collapse
It says that nowhere. HTC claimed they had 90 days and that is a GPL violation. Easy enough to Google that one. It kind of bit them in the ass though - http://thread.gmane.org/gmane.linux.kernel/1048027 and https://freedom-to-tinker.com/blog/sjs/htc-willfully-violates-gpl-t-mobiles-new-g2-android-phone
After much media pressure they backed down and released sources in only 7 days.
GPLv3 gives an explicit 30-day grace period for resolving violations, but the kernel is not v3, it's GPLv2.
I really should stop pointing Gokhan towards fixes since he's a one-way street.
There's enough kernels out there with the "stable" philosophy, some of which barely differentiate from stick sources, so people can go and use those if they want to. Siyah is more a Swiss army knife, but you'll have to be careful not to cut yourself, and it's more fun for some to tinker with the phone.
Click to expand...
Click to collapse
Yup - If someone else wants to port his more aggressive features they can try - it's just not coming from me.
Edit: What you should port though, is update3 sources, those bring significant upgrades in battery life, speed and sound quality.
Click to expand...
Click to collapse
I'll have to look into that - As of a few weeks ago, the AT&T I777 sources were new enough that I9100 kernels (including Siyah) started to be based off of them. The question is - while Update2 to Update3 is a big improvement, is I777 to update3 such an improvement?
I'll have to check those out tonight and diff them.
update3 is a vastly bigger update than what the AT&T sources were to update2. Performance wise, it's a clear-cut, audio too. As for battery life check back in the AOS thread.
Looking forward to see the update being incorporated.
AndreiLux said:
update3 is a vastly bigger update than what the AT&T sources were to update2. Performance wise, it's a clear-cut, audio too. As for battery life check back in the AOS thread.
Click to expand...
Click to collapse
I'm going to start this over the next week - I've split update3 into what should be separate independent patchsets by component (touchkey, audio, wifi, etc.)
Last one is likely going to be the machine-specific ARM stuff - because that means rewriting the clock control patches completely.
I have an inquiry on build times based on the amount of source code needed to create a zip file. These time increments are based on building with an 8GB Ram 1Terabyte drive on a Windows 10 64 bit platform running Ubuntu 14 Trusty ISO VM. Obviously a USB attached external hard drive has some lag in performance. Typically based on my system let's say CyanogenMod 12.1 takes about 36 hours to compile. Would SlimRom 5.1 take less time due to a smaller amount of source code to compile. Is there a way to speed up Slim, AOSP, Paranoid builds?
I imagine anything adding additional functionality on-top of AOSP (like LineageOS) would take longer to compile, but not too significantly.
Best way to speed up compiles is to have (or upgrade) a good CPU with multiple cores. My laptop with a i7-6700HQ takes about an hour to compile LineageOS (a little less with cm14.1, and a little more with lineage-15.0) with bare-metal Fedora Workstation 26.
Just guessing, but running Linux in a VM is probably slowing down your compiling speed?
36 hours? What CPU is that on, an 80286? Oh wait, you have the MSVirus and running the good stuff in a VM.
Try wiping the virus and installing Linux on the bare metal.
On an 8 core AMD Vishara (this CPU is several years old), I can run an AOSP build in ~20 minutes, and that is without ccache.
luciusfox said:
36 hours? What CPU is that on, an 80286? Oh wait, you have the MSVirus and running the good stuff in a VM.
Try wiping the virus and installing Linux on the bare metal.
On an 8 core AMD Vishara (this CPU is several years old), I can run an AOSP build in ~20 minutes, and that is without ccache.
Click to expand...
Click to collapse
My laptop is only a dual core. I am thinking about switching to a dual boot situation. I have a lot of personal stuff on Windows. Yes Windows isn't the greatest platform to work with.
luciusfox said:
36 hours? What CPU is that on, an 80286? Oh wait, you have the MSVirus and running the good stuff in a VM.
Try wiping the virus and installing Linux on the bare metal.
On an 8 core AMD Vishara (this CPU is several years old), I can run an AOSP build in ~20 minutes, and that is without ccache.
Click to expand...
Click to collapse
How much RAM do you have and how many GBs does the aosp code take up?
wrsg said:
How much RAM do you have and how many GBs does the aosp code take up?
Click to expand...
Click to collapse
32 GB RAM here, the full AOSP directory WITH a build for a HiKey 960 is 136 GB.
The .repo/ subdirectory is 34 GB, and the out/ is 77 GB, so the actual AOSP code is about 25 GB.
luciusfox said:
32 GB RAM here, the full AOSP directory WITH a build for a HiKey 960 is 136 GB.
The .repo/ subdirectory is 34 GB, and the out/ is 77 GB, so the actual AOSP code is about 25 GB.
Click to expand...
Click to collapse
I guess you have ccache + compression enabled?
Also is there a specific sub-forum on XDA (or elsewhere) for this sort of discussion?
DISCLAIMER
Code:
USE AT YOUR OWN RISK, NO WARRANTY IS PROVIDED. ONLY TESTED IN H990DS.
Why?
Certain games doesn't work well in the original LOS17.1 kernel for me.
What's new?
alucard hotplug
What's fixed compared to the original kernel?
none, if you don't need the features here just use the original kernel which is better.
Which build should I use?
General build if you don't play heavy games. Likely more stable.
Gaming build if you play heavy games. Likely less stable. Based on gamma but still uses LOS 17.1 sources.
Gaming-OC build if you play heavy games and have good thermals. Likely less stable. 2.34ghz big, 1.88ghz little, 710mhz gpu. Note that default voltages might be too high, use Gaming build first, take notes of the voltages, flash Gaming-OC then fix it up when some frequencies are too high.
Is it plug and play?
Certain new features will be disabled by default.
Pre-configured settings on the new features are not optimized, you should configure it yourself.
You can use smartpack to change adrenoboost, undervolt/overvolt, etc.
If you are throttled by thermal-engine, you will likely to never reach the OC cpu frequencies.
IF YOU DON'T KNOW WHAT YOU ARE DOING, DO NOT TOUCH ESPECIALLY ANYTHING RELATED TO VOLTAGES.
LineageOS 16.0?
Some users say it works, so ¯\_(ツ)_/¯
Download Links
Download here
Changelog
BETA 1
Initial Release
BETA 2
general build skipped, nothing changed.
(Gaming) Voltage Control
(Gaming) OC builds
Special Thanks
mk2000, gamma.
sources
US997 should be labeled US996.
scottyrick said:
US997 should be labeled US996.
Click to expand...
Click to collapse
Thanks for noticing. US997 build has been removed
For anyone that already downloads US997 build, keep in mind it is not a typo of US996, it is really for US997 (LG G6).
lybxlpsv said:
Thanks for noticing. US997 build has been removed
For anyone that already downloads US997 build, keep in mind it is not a typo of US996, it is really for US997 (LG G6).
Click to expand...
Click to collapse
US996 works with the VS995 kernel but shows white screen while booting up. Otherwise works great.
what does that gaming folder means .i am unable know ..about these files ..plzz help
any update for this kernel? it's very amazing for battery life and performance
H918
I flashed general build and what I have noticed.
Battery life improved.
Games runs smooth.
Phone runs cooler now.
Overall very stable kernel.
Ir blaster is not working kindly fix it in another build.
Thanks for your great work. ?
Is it possible to add ttl support in the next build?
So happy to see someone still willing to spend time developer kernel for v20, so I just want to see if it's possible
No general build
Hello.. Thanks for the work you are doing. But i can't find general build. Thanks
princedede said:
Hello.. Thanks for the work you are doing. But i can't find general build. Thanks
Click to expand...
Click to collapse
I believe its in the beta 1 folder
Does PD charging work?
I was tried on h990ds I run antutu benchmark and I get score just 94.860
How it can be?
gading_aji said:
I was tried on h990ds I run antutu benchmark and I get score just 94.860
How it can be?
Click to expand...
Click to collapse
What are your thermals like? If ur cpu is getting too hot, it`ll lower it`s clockspeed
xxseva44 said:
What are your thermals like? If ur cpu is getting too hot, it`ll lower it`s clockspeed
Click to expand...
Click to collapse
cpu thermal is throttling, i will try run antutu 5 times with 1,5 Ghz Cpu Speed and 5 time with 2,1 Ghz CPU Speed
gading_aji said:
cpu thermal is throttling, i will try run antutu 5 times with 1,5 Ghz Cpu Speed and 5 time with 2,1 Ghz CPU Speed
Click to expand...
Click to collapse
I'd recomend removing the crap thermal pad and replacing it with thermal paste like arctic mx-4. I did it and my thermals are very good, the cpu barely goes over 55 degrees celsius under heavy load. Before the mod i was hitting 70-80 degrees
xxseva44 said:
I'd recomend removing the crap thermal pad and replacing it with thermal paste like arctic mx-4. I did it and my thermals are very good, the cpu barely goes over 55 degrees celsius under heavy load. Before the mod i was hitting 70-80 degrees
Click to expand...
Click to collapse
My device using LOS 17 and this kernel always loch CPU clockspeed @ 1,19 Ghz and it can't be modified
I don't know, this bug from kernel or the ROM??
could be battery
here's few things you can try :
using the thermal engine I put on the drive link.
This can be dangerous since it is tuned for my phone or you can use gamma's thermal engine flashable.
Disable BCL, this is dangeorus and may shorten your battery lifespan. ONLY USE THIS FOR TESTING.
Code:
echo -n disable > /sys/class/power_supply/bcl/device/mode
if BCL fixed it then you need a new battery and be sure to restart so bcl enables again.
lybxlpsv said:
could be battery
here's few things you can try :
using the thermal engine I put on the drive link.
This can be dangerous since it is tuned for my phone or you can use gamma's thermal engine flashable.
Disable BCL, this is dangeorus and may shorten your battery lifespan. ONLY USE THIS FOR TESTING.
if BCL fixed it then you need a new battery and be sure to restart so bcl enables again.
Click to expand...
Click to collapse
So the battery cause the clock speed lock at 1,19 Ghz??
This is a nice update to Gamma, but unfortunately anything beyond the camera-fixed-but-otherwise Gamma kernel in the `MAGISK-TWEAKS` directory doesn't have a functioning IR sensor - even in the supposed 'General' build. If this project is still in development, would it be possible to add the feature back in? It's a lot to ask for, but for those who use a V20 as a secondary device specifically for some of these (now) niche hardware features, it's almost the final decision between using this kernel, or not.
...I'd say 'other kernels' but, there really isn't anything else for new AOSP-based ROMs beyond, uh, Gamma.
What is the difference in between this kernel and last gamma kernel 20.0? Thanks