So, my question is, why do we want the 3.0 Kernel for Nook Tablet again? From what I recall, there were absolutely no changes from kernel 2.6 to 3.0, other than the naming. Only the "alpha-manliness", and the shuffle of old drivers or something along those lines.
Any Ducati stuff is provided in acclaim_update.zip isn't it?
Anyways, if someone could answer that, that'd be great.
Ok, I am not part of the dev team and I got my NT too late to have read the original reasoning behind development of a 3.0 kernel but after a bit of research I think I may have at least part of the picture.
The main reason for the development of a 3.0 kernel is to gain access to the Ducati hardware integrated into the OMAP 4430 that the NT uses. With the 2.6 kernel we can use only the dual core Cortex A9 part of the processor but if we can develop a Ducati driver it will allow use to use the Cortex M3 dual core (four cores total) for hardware video acceleration.
This is proving to be a challenge because TI will not release the source for the Ducati related kernel elements; they will only give us a binary version which is crippled for our device because it uses the wrong watchdog timer (GPtimer 11 vs GPtimer 10 which we need).
This all requires Kernel 3.0 because the binary for Ducati is built using this kernel. Aside from that, ICS is built for the 3.0 kernel branch and we should be keeping up (if not one step ahead) if possible.
That is what I've gotten so far but if any devs want to step in and correct, clarify, or add anything else, please feel free. Thanks guys for all your hard work!
Android ICS v4 was build upon kernel v3 and also the framework (api's)
It provides some elemental changes over Gingerbread like HWA of the gui so in plain words it takes the burden off the cpu and uses the gpu like Nvidia VDPAU (Video Decode and Presentation API for Unix)
http://en.wikipedia.org/wiki/VDPAU
And Windows DXVA V2
http://msdn.microsoft.com/en-us/library/windows/desktop/cc307941(v=vs.85).aspx
http://en.wikipedia.org/wiki/DirectX_Video_Acceleration
Hardware-accelerated 2D drawing
All Android-powered devices running Android 4.0 are required to support hardware-accelerated 2D drawing. Developers can take advantage of this to add great UI effects while maintaining optimal performance on high-resolution screens, even on phones. For example, developers can rely on accelerated scaling, rotation, and other 2D operations, as well as accelerated UI components such as TextureView and compositing modes such as filtering, blending, and opacity.
As everyone thinks that no changes where made on kernel transportation to v3 from 2.6, later on many arm optimizations where sync to git from different sources that help to make the v3 kernel more feature full over v2.6.
For starters,
Linaro is pushing more and more advancements to the git for v3.
Ubuntu decided to support arm hardware in Server and Userbase because of those changes.
They are putting out a Plasma tablet with Arm Cortex A9 cpu 512mb Ram with kde Plasma interface as well as pushing theirs code onto the git also.
So in the v3 kernel we see things done right.
Another proof that kernel v3 done miracles to arm is the XBMC project.
Now we have an xbmc version for arm also.
This is no coincidence at all.
An important factor to all this is that Android does not run on a stock Linux kernel. The source code for each Android release also includes a large number of Android-specific changes to the Linux kernel, including custom features and even entire subsystems. Each release of the Android OS is developed hand-in-hand with a specific kernel version and its changes, and ICS was developed around a modified 3.0.1 kernel. Using an older kernel version could potentially require work in patching newer changes into an old kernel or hacking in workarounds instead of just focusing on drivers. This is why most ROMs aren't just jumping straight to the newest Linux 3.3 either. I don't know any specifics about what changes are important though
Many drivers available from all these outside sources have been built around this same Android 3.0.1 kernel version too, so the chances of issues are much smaller if you stick to the same version
Also, to clarify about the Linux numbering: you're correct that the 3.0 version itself didn't include any big changes over 2.6.39 so as to keep the focus on simply replacing "2.6" with "3" while sticking with the same development process. However since they started the 2.6 branch many years ago they have constantly added new features, new frameworks, and all kinds of significant changes in the 2.6.X/3.X sub-versions as the code became ready. There wasn't simply a 2.6 kernel there were many 2.6 kernels, and it changed a lot over time from the initial 2.6.0 version just as it continues to evolve with each 3.X version
demetris_I said:
Android ICS v4 was build upon kernel v3 and also the framework (api's)
It provides some elemental changes over Gingerbread like HWA of the gui so in plain words it takes the burden off the cpu and uses the gpu like Nvidia VDPAU (Video Decode and Presentation API for Unix)
http://en.wikipedia.org/wiki/VDPAU
And Windows DXVA V2
http://msdn.microsoft.com/en-us/library/windows/desktop/cc307941(v=vs.85).aspx
http://en.wikipedia.org/wiki/DirectX_Video_Acceleration
Hardware-accelerated 2D drawing
All Android-powered devices running Android 4.0 are required to support hardware-accelerated 2D drawing. Developers can take advantage of this to add great UI effects while maintaining optimal performance on high-resolution screens, even on phones. For example, developers can rely on accelerated scaling, rotation, and other 2D operations, as well as accelerated UI components such as TextureView and compositing modes such as filtering, blending, and opacity.
As everyone thinks that no changes where made on kernel transportation to v3 from 2.6, later on many arm optimizations where sync to git from different sources that help to make the v3 kernel more feature full over v2.6.
For starters,
Linaro is pushing more and more advancements to the git for v3.
Ubuntu decided to support arm hardware in Server and Userbase because of those changes.
They are putting out a Plasma tablet with Arm Cortex A9 cpu 512mb Ram with kde Plasma interface as well as pushing theirs code onto the git also.
So in the v3 kernel we see things done right.
Another proof that kernel v3 done miracles to arm is the XBMC project.
Now we have an xbmc version for arm also.
This is no coincidence at all.
Click to expand...
Click to collapse
Sounds good. But the nook Tablet is running Gingerbread, and it gets Ducati features. Doesn't that mean a 2.6 Kernel suffices the Ducati Susbsystem? Does moving to Kernel 3.0.x make it easier to crack Ducati? Hmm.
soshite said:
Sounds good. But the nook Tablet is running Gingerbread, and it gets Ducati features. Doesn't that mean a 2.6 Kernel suffices the Ducati Susbsystem? Does moving to Kernel 3.0.x make it easier to crack Ducati? Hmm.
Click to expand...
Click to collapse
Ducati wasn't the point because as you pointed out it already works with the original kernel, and it not working yet with this 3.0 kernel is an unfortunate side effect of the real goal.
Moving to a newer Android kernel apparently makes it much easier to get proper graphics acceleration working for apps and general user interface components. This hardware acceleration of the UI is why ICS can feel so much smoother than Honeycomb or Gingerbread. Without the proper kernel I think they have to resort to dirtier hacks into the rest of ICS to make it run properly. I'm admittedly a little fuzzy on the details though
Lets just say that moving to Kernel v3 will make full use of our hardware, something GB doesn't do right now.
boomn said:
This hardware acceleration of the UI is why ICS can feel so much smoother than Honeycomb or Gingerbread.
Click to expand...
Click to collapse
AFAIK Honeycomb has already the UI acceleration. But I haven't had any device with HC, is ICS really much smoother then HC? I didn't think so.
Aleq said:
AFAIK Honeycomb has already the UI acceleration. But I haven't had any device with HC, is ICS really much smoother then HC? I didn't think so.
Click to expand...
Click to collapse
The thing is, Honeycomb is really heavy on the device. Honeycomb would be slower than ICS, as it would be ported and contains more contents than ICS. ICS was made to be the faster successor to HC.
Aleq said:
AFAIK Honeycomb has already the UI acceleration. But I haven't had any device with HC, is ICS really much smoother then HC? I didn't think so.
Click to expand...
Click to collapse
I was mistaken and you are correct. However, something under the hood was definitely changed or tweaked in regards to acceleration and how it is used because ICS does feel much smoother and more responsive throughout than Honeycomb did
I searched a bit and found this helpful article. Here are the most relevant quotes:
Android 3.0 Honeycomb gave developers the ability to turn on hardware acceleration, but it wasn’t toggled by default.
Click to expand...
Click to collapse
According to Romain Guy and Chet Haase (Android engineers):
“With this new pipeline, all drawing operations performed by the UI toolkit are carried out using the GPU. You’ll be happy to hear that Android 4.0, Ice Cream Sandwich, brings an improved version of the hardware-accelerated 2D rendering pipeline to phones, starting with Galaxy Nexus. In Android 4.0 (API level 14), hardware acceleration, for the first time, is on by default for all applications.”
Click to expand...
Click to collapse
Related
So I was just looking around the Qualcomm open source (CodeAurora) repositories and noticed that lots of interesting things are going on over there for the qsd8x50 that aren't yet in our N1 kernels.
One of the most potentially useful things to us, is adaptive undervolting, that always chooses the optimal voltage level based on the current temperature and silicon process variations.
https www codeaurora.org/gitweb/quic/chrome/?p=kernel.git;a=commit;h=621d0e14e6fcf454974634cf822f06fba1bd6816
If someone could get this into an N1 kernel, we wouldn't need any more experimentation with undervolting and could always run at the maximum possible stable voltage.
Other interesting changes include USB host support (although it's unlikely the N1 hardware is physically wired to allow for this):
https www codeaurora.org/gitweb/quic/chrome/?p=kernel.git;a=commit;h=109894cac8d01c6273cfa0466f7823a04e919bea
Unfortunately, the Chromium kernel for MSM/QSD seems to be structured quite differently and being worked on by a different team to the Android kernel. Still, it'd be nice to see someone attempt to port at least the AVS patch to a CM kernel.
p.s. can a moderator please approve my account to directly include links? This manual link-munging is getting annoying
This sounds interesting
I know a lot of the devs here check out Qualcomm's latests postings, so hopefully they are aware of this...
Also of interest is their framebuffer driver. We need it in the N1 kernel to use their X11 driver.
Has anyone had any luck getting a CAF kernel booting on the N1?
Markdental said:
I know a lot of the devs here check out Qualcomm's latests postings, so hopefully they are aware of this...
Click to expand...
Click to collapse
Yeah I know, but this is their Chromium/ChromeOS kernel, not their Android kernel. Might have gone unnoticed (I for one, had not thought to look there -- I'd have thought the only Chrome-specific kernel changes would've been the X11 driver -- why should platform-power-management changes not be shared across both kernels?)
I ported AVS code to the N1 kernel.
You can download the experimental version here:
http://forum.xda-developers.com/showthread.php?t=654416
AVS kernel is very experimental, and I expect it not to be fully stable.
Also, it looks 1.275v is not really enough for 1.1 GHz - at least AVS complains that it cannot find stable voltage.
Ivan Dimkovic said:
Also, it looks 1.275v is not really enough for 1.1 GHz - at least AVS complains that it cannot find stable voltage.
Click to expand...
Click to collapse
Funny that: a processor rated for 1 GHz (in a world where if they could get away with selling it as a 1.1 GHz processor they certainly would have) isn't actually capable of 1.1 GHz without compromising stability and/or lifetime. Who'd have thought
Cheers for porting it to your kernel though, I'll be interested to see if it makes much difference to battery life.
I got no problems with AVS so far - I will release new kernel update tonight with AVS with no overclocking, as AVS and overclocking do not mix well for some people. Also, I provided the patch-code on my github, so other kernel developers can use AVS too, if they wish. There is still an ugly hack inside (one liner, though) which I will fix tonight, too.
Regarding "getting away" with faster CPU (Qualcomm) - I am not really sure if they would do it. There are market pressures, and CPUs are not always binned according to test validation - rather, other factors are at play, such as market demand.
So, it does happen - if someone is lucky, that is - to receive a CPU which could be binned higher, but it was still released at lower frequency because of market demands.
Intel is a very good example of such practice, and I am sure Qualcomm is no different as this is a huge market.
Ivan Dimkovic said:
I got no problems with AVS so far - I will release new kernel update tonight with AVS with no overclocking, as AVS and overclocking do not mix well for some people. Also, I provided the patch-code on my github, so other kernel developers can use AVS too, if they wish. There is still an ugly hack inside (one liner, though) which I will fix tonight, too.
Regarding "getting away" with faster CPU (Qualcomm) - I am not really sure if they would do it. There are market pressures, and CPUs are not always binned according to test validation - rather, other factors are at play, such as market demand.
So, it does happen - if someone is lucky, that is - to receive a CPU which could be binned higher, but it was still released at lower frequency because of market demands.
Intel is a very good example of such practice, and I am sure Qualcomm is no different as this is a huge market.
Click to expand...
Click to collapse
I'll study this for integration in my .32 kernel...I'll have plenty of time once Holy Week vacation starts here.
Ivan Dimkovic said:
I got no problems with AVS so far - I will release new kernel update tonight with AVS with no overclocking, as AVS and overclocking do not mix well for some people. Also, I provided the patch-code on my github, so other kernel developers can use AVS too, if they wish. There is still an ugly hack inside (one liner, though) which I will fix tonight, too.
Regarding "getting away" with faster CPU (Qualcomm) - I am not really sure if they would do it. There are market pressures, and CPUs are not always binned according to test validation - rather, other factors are at play, such as market demand.
So, it does happen - if someone is lucky, that is - to receive a CPU which could be binned higher, but it was still released at lower frequency because of market demands.
Intel is a very good example of such practice, and I am sure Qualcomm is no different as this is a huge market.
Click to expand...
Click to collapse
No doubt about it. Look at the Desire for example. It will be equipped with the 1ghz Snapdragon but will be underclocked to 768mhz to preserve battery life. So while it is certified for higher speeds HTC feels the market would prefer longer battery life over a little bump up in cpu speed
intersectRaven said:
I'll study this for integration in my .32 kernel...I'll have plenty of time once Holy Week vacation starts here.
Click to expand...
Click to collapse
Out of curiosity, what advantages if any do you see with the .32 kernel over .33?
jlevy73 said:
Out of curiosity, what advantages if any do you see with the .32 kernel over .33?
Click to expand...
Click to collapse
Well, I've been using it for longer than .33 since I found it to be more responsive and a lot more stable with my 3d live wallpapers. Its also smaller when compiled so I can enable the compiler optimizations with ease.
intersectRaven said:
Well, I've been using it for longer than .33 since I found it to be more responsive and a lot more stable with my 3d live wallpapers. Its also smaller when compiled so I can enable the compiler optimizations with ease.
Click to expand...
Click to collapse
Also, the upstream (AOSP) MSM kernel tree is still at .32... I would guess they may be stabilizing for a release as they've merged the -stable patchseries too (2.6.32.9 etc).
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.
02/12/11: Froyo boots, stability issues resolved, all used modules from source except graphics. Problems: radio does not work, camcorder crashes the camera app, likely more issues. Big thanks to TheBirdman, SuperCurio and all the other devs working like myself out there to make this dream a reality. Gingerbread will come after Froyo is stabilized. As promised progress is being made.
This is not a Blazed kernel but will share in code fixes and versatility.
Thanks to TheBirdman, SuperCurio and others who's patches are pulled from TheBirdmans git to improve Fascinate compatibility.
The Eclair source appeared to be coded by multiple seperate teams simultaniously whilst Froyo source appears to be developed by one team and the sammy sources for the devices with Froyo are incrementally getting more updates as they move from one device to another.
Source will be posted soon, i am traveling right now and wanted to share this breakthrough from earlier today. Hint for those who can not wait the I9000 Samsung source contains almost everything you need except a graphics driver and a proper config, compare fascinate_defconfig, aries_eur_defconfig and the eclair defconfig or pull config from this kernel ;-)
The link below is for an alpha quality non-voodoo test kernel with ext4, ipv6, and full netfilter built in plus alot of extra modules stored in /system/kmodules:
02/16/11: Froyo Source Now Online!
03/10/11: Source pulled from laststufo's ULTIMATE SUPER OPTIMIZED Kernel for Galaxy S I9000
Wifi is working as client, Sound is working again, 3G radio that sometimes worked has stopped working again. This maybe a good thing though as it has indicated we may have been side stepping too much and avoiding drivers that may be more compatible than what we were actually using. The cpu is spot on, the sound is now using wm8994 aries and not wm8994 universal master. I suspect many incompatibilities in the platform still, but progress is being made. I think we were all just seeing too little with tunnel vision because of stress and perhaps a lack of sleep.
There are a number of goodies from laststufo in this tree (ramzswap, compcache, what appear to be usb host otg support just to name a few) non of which I have tested on fascinate but all of which compiled without error. I have tested overclock up to 1200Mhz, it supports up to 1.6Ghz (I would be very careful about anything past 1.2Ghz). VSF (Variable Screen Frequency) sync is broken ( a new feature from laststufo ) until replacement for the accel_xyz function of the smb380 is found, as the smb380 is not supported on the Fascinate, just as the yamaha compass driver is not supported. VSF's purpose is to save battery by reducing screen refresh rate when the device is being used in a minimal activity type situation.
I have not posted working binaries or full source to git yet, but I plan to have a new binary voodoo and non-voodoo up with source hopefully by sometime monday (but please don't hold me to it if I'm a little late)
Source:
GITHUB: http://www.github.com/sirgatez Last Updated 02/12/11
Binaries:
Non-Voodoo: http://db.tt/Y66iNVu - Proof Of Concept Alpha 02/12/11
Sent from my SCH-I500 using XDA App
I think I'm in love with you.
Sad news: it would only be bromance.
Anyhow, thank you so much for your hard work, and please keep it up!
It's incredible what you guys can do.
yay.. its just a matter of time till u make some magical work in froyo kernel.
i think punkkaos mentioned in one of his tweets that he was working on kernel, and got hardware acceleration on UI working but had graphical glitches, but he said that it was awesome fast.
Would that be possible here too ?
I will be looking forward to seeing this beast run on my phone once it hits the beta stage.
Maybe I'm mislead, but doesn't the i9000 froyo kernel use an rfs filesystem?
Sent from my SCH-I500 using XDA App
papstar said:
Maybe I'm mislead, but doesn't the i9000 froyo kernel use an rfs filesystem?
Sent from my SCH-I500 using XDA App
Click to expand...
Click to collapse
I think the nexus s is the only recent Samsung phone not using rfs. The rfs drivers in this kernel are in the stock i9000 source.
Sent from my SCH-I500 using XDA App
I should have source up by the end of the day heading home from hospital now.
I did some googling, correct me if I am mistaken but I can not seem to find the kernel module source for s3c_bc, s3c_lcd, or pwrsrv outside of Eclair. The eclair module for pwrsrv fails to boot, and the sizes of all 3 compiled binaries do not come close to the froyo ones from samsung. Both s3c modulea are less that or about 100k in froyo, eclair and eclair compiled against froyo are closer to 300k each. PowerVR driver is like 350k on froyo, and eclair and eclair compiled against froyo are 1.8/1.9MB. I did find a newer powervr driver from imagination last night but have to rework some code make it compile, and ti has the most recent driver from imagination but will not share unless you purchased a 1,600 evaluation board.
Sent from my SCH-I500 using XDA App
SirGatez said:
ti has the most recent driver from imagination but will not share unless you purchased a 1,600 evaluation board.
Click to expand...
Click to collapse
I can send a lot curse words TI's way atm.
Btw, how much performance do these drivers improve ?
3d accel nor graphics work without them. Sammies binary works as shown in the alpha posted but ti isnt to blame, imagination (imageon) makes and releases/licenses the driver and its code.
Just read an article saying they may opensource it in 3rd quarter this year I dont see that hindering us much right now with froyo, we can always dissassemble and recompile the binaries if we are left no other options to ensure gingerbread compatibility. Nexus S binary modules should work for gb testers at the moment, not sure how different froyo and gb powervr sgx drivers are right now but their are seemingly major internal changes from eclair to froyo. Every google result says both use the same gpu.
But Samsung is to blame for the lack of opensource froyo s3c_bc and s3c_lcd modules. But they look portable to froyo at the moment, will delve deeper into rabbit hole soon...
Edit: I have not tried to boot without loading these modules but when I compile and use the eclair powervr driver for froyo it driver load loops then boot loops then shuts down. The phone may work in 2d without them but I am doubtful. The kernel does have enough internal code (s3c_fb, s3c_cfb, etc) to display the i9000 startup image but the rest of the drivers are supposed to load before the bootanimation plays.
Sent from my SCH-I500 using XDA App
SirGatez said:
Just read an article saying they may opensource it in 3rd quarter this year I dont see that hindering us much right now with froyo, we can always dissassemble and recompile the binaries if we are left no other options to ensure gingerbread compatibility. Nexus S binary modules should work for gb testers at the moment, not sure how different froyo and gb powervr sgx drivers are right now but their are seemingly major internal changes from eclair to froyo. Every google result says both use the same gpu.
But Samsung is to blame for the lack of opensource froyo s3c_bc and s3c_lcd modules. But they look portable to froyo at the moment, will delve deeper into rabbit hole soon...
Edit: I have not tried to boot without loading these modules but when I compile and use the eclair powervr driver for froyo it driver load loops then boot loops then shuts down. The phone may work in 2d without them but I am doubtful. The kernel does have enough internal code (s3c_fb, s3c_cfb, etc) to display the i9000 startup image but the rest of the drivers are supposed to load before the bootanimation plays.
Sent from my SCH-I500 using XDA App
Click to expand...
Click to collapse
Damn, that's neat info. Where does one go to learn all this neat stuff about kernel, decompiling binaries and then compiling them again for another OS ?
StDevious said:
Damn, that's neat info. Where does one go to learn all this neat stuff about kernel, decompiling binaries and then compiling them again for another OS ?
Click to expand...
Click to collapse
Kernel hacking is very similar to any other reverse engineering effort, an under standing of asm is needed, as well as the file layout of thr target binaries.
Although technically reverse engineering by way of of binary decompilation is copyright infringement and a breach of most software usage licenses, but so is sharing binaries from one platform to another dispite the purpose.
Either way that isn't something I will be working on just yet unless an opensource driver for this surfaces we will use sammies for now and concentrate on making what we have stable. Fixing the radio and testing the other hardware are priority since the current binary froyo graphics driver does work atm. We will get an opensource version working later, if not then we worry about the the black box problem.
Sent from my SCH-I500 using XDA App
About 2 hours more research later I learned that a portion but not all of the PowerVR SGX/MDX drivers are open source, they are released like binary blobs with the open sourced portion of the driver enclosing the closed sourced blobs to function (much like how NVidia and ATI began their Linux Driver crusade), I will attempt to contact TI / Imagination for the open source portion of the drivers, they do not have them posted for public consumption but should have no problem providing access under the OSS/GPL. If anyone has these already they can send me a PM and it will save some time, likely the closest port that should work will likely be TI's OMAP34xx PowerVR SGX with modifications as it is already Linux compatible. There are about 3-4 versions of the driver, the external installer version does not match the internal library versions, v1/v2 is Pre-Samsung-Eclair/Samsung-Eclair, and I have downloaded v3 and attempting to get it to work with Froyo, I am not sure what version Froyo uses, v4 is avail for OMAP3xxx developers from TI linked to a development board that they sell. Not sure what version is available by request. I downloaded v3 but the problem I'm having with v3 is compiling has a data type conflict that I am attempting to resolve between the portions I pulled from v2 for Samsung compatibility.
Go SirGatez go
Good go, appreciate the effort for the greater good.
SirGatez said:
Kernel hacking is very similar to any other reverse engineering effort, an under standing of asm is needed, as well as the file layout of thr target binaries.
Although technically reverse engineering by way of of binary decompilation is copyright infringement and a breach of most software usage licenses, but so is sharing binaries from one platform to another dispite the purpose.
Either way that isn't something I will be working on just yet unless an opensource driver for this surfaces we will use sammies for now and concentrate on making what we have stable. Fixing the radio and testing the other hardware are priority since the current binary froyo graphics driver does work atm. We will get an opensource version working later, if not then we worry about the the black box problem.
Sent from my SCH-I500 using XDA App
Click to expand...
Click to collapse
is there like a link to guide or a book to learn ?
I know it's too early for feature requests... so I'm just going to leave this here... you know, for fun.
http://forum.xda-developers.com/showthread.php?t=709135
No pressure.
SirGatez said:
Although technically reverse engineering by way of of binary decompilation is copyright infringement and a breach of most software usage licenses, but so is sharing binaries from one platform to another dispite the purpose.
Click to expand...
Click to collapse
Nearly all of the innovators that make beautiful things happen with technology are in violation (or at least a gray area) of the law. It really is a shame.
I wonder how much bribe money it took to get the DMCA passed? I'm sorry, I meant "political funding".
Source is online now! Sorry for the delays, Enjoy!
http://www.github.com/sirgatez
I'm working on porting some features from Blazed into Froyo now, git will be updated once I verify everything works. To compile Froyo use the Fascinate_Blazed_defconfig. You will need need to use the stock modules pvrsrvkm.ko, s3c_lcd.ko, s3c_bc.ko for graphics to work. Use of hotspot_event_monitoring.ko, dhd.ko, dpram.ko, dpram_recovery.ko may also allow for operation radio and wifi although I have not tested this, so consider radio operations to still be broken, I am working on the issue.
I did manage to compile versions 2 (From Eclair, did not try Eclairs older EGL libraries with Froyo), 3 (Had android EGL libraries 1 subversion lower than stock Froyo) and 4 (no android egl libraries were included) of the PowerVR drivers and something is amiss and still results in a boot loop, something doesn't seem to be compatible, seems like I get missing library defines no matter how I try.
If someone has intimate knowledge about the PowerVR 3D and EGL on android and could PM me I would like to get some help on getting a fully working compile from source of the drivers that works. Any TI/OMAP3 experience with this driver should be applicable to this situation. I have not posted these drivers on git because there is a clickwrap license on the, you can get them from TI's website, some of them require a login to download, some of them are instant with no login.
I expect full source working drivers for all other devices except graphics within 7 to 14 days once the bugs and incompatible code is resolved, again the dhd wifi drivers are NOT compiling to the same size as the one provided by Samsung, so something seems fishy. If anyone from the internal Samsung Froyo dev team would like to help shed some light on why dhd.ko, pvrsrvkm.ko, s3c_lcd.ko, s3c_bc.ko all compile from the posted source to files 3-8 times the size of those included in Samsung's stock roms it would help progress greatly. Oh yes and I will not reveal any identifying information in exchange for your help unless you request it
Making progress with dpram/gpio control lines. Once I get this right the radio will be working like a charm. Dpram also controls operation of other major hardware such as camera, bluetooth, wifi, in addition to cellular. These devices all work independantly of each other but the dpram module handles the traffic and control i/o.
The galaxy phones while all sporting similar hardware have slightly different ways of controlling them.
Sent from my SCH-I500 using XDA App
Samsung released the source for froyo for the epic today.
http://www.androidcentral.com/samsung-releases-source-epic-4g-eb13-froyo-update
This is most likely of limited usefulness but hopefully a sign we wont have to wait long for the fascinate source.
I've heard/read that ONLY honeycomb makes use of the dual core.
So what's the advantage of having a dual core phone running gingerbread?
Nvm I found some information.
Sry for makimg a new useless topic
Where did you find the information?
Please post the Link!
All of the information I've read shows that Ice Cream should be the build with this integrated.
It's somewhat baffling that it's taken this long considering that for the average phone user, how smooth the phone is plays a huge part in whether they like it or not.
iOS has had GPU UI acceleration since its inception, how have the Android team members let this slide? Is it simply because the implementation requires a massive structural re-write?
Tossing the 2D UI acceleration over to the GPU should theoretically increase the speed of the OS as well, since it frees up the CPU to focus on its own tasks.
MustWarnothers said:
iOS has had GPU UI acceleration since its inception, how have the Android team members let this slide? Is it simply because the implementation requires a massive structural re-write?
Tossing the 2D UI acceleration over to the GPU should theoretically increase the speed of the OS as well, since it frees up the CPU to focus on its own tasks.
Click to expand...
Click to collapse
Caching is primarily what makes it so smooth on the iPhone, not GPU acceleration; though that helps a fair amount, also. The lack of heavy use of caching everything in the UI for what seems like all Android UIs is what has baffled me about Android UIs. Home screen launcher replacements like LauncherPro use it, and it makes everything nice and silky smooth. I've honestly been thinking that most UI designers for the hardware companies simply do not know what they are doing.
MustWarnothers said:
All of the information I've read shows that Ice Cream should be the build with this integrated.
It's somewhat baffling that it's taken this long considering that for the average phone user, how smooth the phone is plays a huge part in whether they like it or not.
iOS has had GPU UI acceleration since its inception, how have the Android team members let this slide? Is it simply because the implementation requires a massive structural re-write?
Tossing the 2D UI acceleration over to the GPU should theoretically increase the speed of the OS as well, since it frees up the CPU to focus on its own tasks.
Click to expand...
Click to collapse
it's not that simple...ios is missing a lot of features. i read that it doesn't support java and just object-oriented C++.
Since android was started, phone developers have pushed it in directions that Google didn't originally plan for. That's why the nexus s only had single core, and afaik, all the dual core phones have software on top of android to manage the dual core processing, which doesn't really do much for them. yes they're faster, but i think not as fast as they could/should be.
i'm assuming the next nexus will be a dual core, and with android that has support for them. if so, it'd blow all dual cores away to this point, because processor management is more efficient the lower in the stack it's handled.
however, what with the nexus s 4g being recently released, i'm not expecting the next nexus to be around anytime soon as G focus on tablets.
Since the SGS2 is so fast for web browsing and flash content, as well as UI, what type of magic do they do if they aren't altering the basic Android system? Does it involve using dual-core? How specific are the Samsung optimizations and are they low-level enough for Google to say this would be great in Ice Cream and thus steal that optimization from them? Is TouchWiz actually faster than stock Android? Or is that impossible since it is built on top of Android? Will the browser speed translate to other installed browsers, or is it specific to the stock browser? I really don't know how far Samsung or any other manufacturer can customize the software beyond just superficial skins and whether or not deep customizations change the system fundamentally and possibly break certain apps.
I didn't really investigate this issue deeply, but I think it works out like this:
Right now, the android sdk (2.3) provides no means to use more than one CPU core.
Still, multicore CPUs will increase performance because background processes can use CPU time on the core not being used by the running app.
This also applies to garbage collection (GC) which happens periodically (I guess you can trigger it manually too) whilst an app is running. With more than one core, the GC won't block the app which makes it feel "smoother".
I remember reading about Google's plans to improve multicore-support in android 2.4. It will take some time for existing apps to use it though (like it's happened with desktop applications).
Then just imagine the performance of the SGS II device with hardware acceleration support.
MustWarnothers said:
All of the information I've read shows that Ice Cream should be the build with this integrated.
It's somewhat baffling that it's taken this long considering that for the average phone user, how smooth the phone is plays a huge part in whether they like it or not.
iOS has had GPU UI acceleration since its inception, how have the Android team members let this slide? Is it simply because the implementation requires a massive structural re-write?
Click to expand...
Click to collapse
Since Honeycomb utilizes GPU for UI rendering, I guess it will be available on Ice Cream too.
Android is handicapped by the big range of hardware used by manufacturers. Some GPUs are simply too slow or have other issues which will make GPU acceleration fail. This is not an issue for Apple, because there is no hardware choice on iOS.
silverwolf0 said:
Since the SGS2 is so fast for web browsing and flash content, as well as UI, what type of magic do they do if they aren't altering the basic Android system? Does it involve using dual-core? How specific are the Samsung optimizations and are they low-level enough for Google to say this would be great in Ice Cream and thus steal that optimization from them? Is TouchWiz actually faster than stock Android? Or is that impossible since it is built on top of Android? Will the browser speed translate to other installed browsers, or is it specific to the stock browser? I really don't know how far Samsung or any other manufacturer can customize the software beyond just superficial skins and whether or not deep customizations change the system fundamentally and possibly break certain apps.
Click to expand...
Click to collapse
All parts of android (2.3) are open sourced, so Samsung can customize anything they want. They don't have to release the changed version as open source though (except for the GPLed parts, like the kernel) - so we'll probably never know what they've been doing.
german wikipedia says that gingerbread 2.3.3 features dual-core support ...
Link it please, thats odd.
My German is bad as I only read it for a couple of year but here is the Wikipedia page http://de.wikipedia.org/wiki/Android_(Betriebssystem)
At the bottom you have "Dual-Core-Unterstützung" on 2.3.3 which means it support it.
But as always Wikipedia is never 100% correct so who know
I read that they will re-release a gingerbread version (2.4?) that will take advantage of Dual-core apps. So basically, they add dual-core support and it will also still be gingerbread but version 2.4 of android.
Come to think of it, they did the same thing with Eclair (2.0 and 2.1) already.
Hope this helps
I think they have already done that with "Gingerbread 2.3.3", Instead of calling v 2.4 GINGERBREAD as well, they made the changes in "Gingerbread" and gave it versioning 2.3.3.
Thats what it looks like all on Wikipedia pages. Highlights 2.3.3 as a Major release.
Yes, the wiki says that dual-cores are supported from 2.3.3 and it says too that dual-core-apps are supported on single-core smartphones! --> Thats an indication for real dual-core support!
I'm just waiting for when Android decides to implement GPU UI acceleration.
Even if apps are offered dual core support, if both of those cores are still working on UI animations instead of tossing it to the GPU, it seems like 3 steps forward, 2 steps back.
As I understand it, Gingerbread (2.3) offers limited dual-core support. If your phone has a 2nd core available, then it will move the Garbage Collector onto the 2nd core which means there will be a lot less lag in applications and games when the GC fires off to remove unused resources.
http:/ /developer.android.com/sdk/android-2.3-highlights.html
It's under the 'enhancements to games' section I believe.
Honeycomb (3.0) offers full UI hardware acceleration and makes full use of both cores - so wait for Ice Cream to come to phones and it will be fully supported.
I know that wikipedia isnt always right but if i assume that it is right this time it says that what you just wrote Xailter was integrated in 2.3 and real dual-core support in 2.3.3 :
2.3 features:
Linux-Kernel 2.6.35.7
Unterstützung von WebM
Unterstützung von HTML5 Audio [31]
Unterstützung von Google TV
Unterstützung von Near Field Communication
Parallele Garbage Collection für ruckelfreiere Animationen
verbesserte Integration von sozialen Netzwerken
Unterstützung von Gyroskopen (nicht zu verwechseln mit Bewegungssensoren) und anderen Sensoren (u.a. Barometer, Schwerkraftsensor)[32]
Integrierter SIP-Client für VoIP[33]
Integrierter Downloadmanager[33]
Unterstützung des Ext4-Dateisystems[34]
translated something like "parallel garbage collection for smoother animations"
while 2.3.3 features:
Dual-Core-Unterstützung
Unterstützung von Dual-Core-Apps auf Single-Core-Geräten
verbesserte Unterstützung der NFC-Technik
verbesserte Bluetooth-Unterstützung
kleinere Verbesserungen
which means dual-core support
support for dual-core apps on single-core-devices
improved support of nfc
improved support for bluetooth
minor improvements
if we can believe in what wikipedia says ... 2.3.3 features dual-core support
and i think it is true because it would just make sense to support the hardware that is releasing right now
source: de. wikipedia. org/wiki/Android_%28Betriebssystem%29#Versionsverlauf
sry for the spaces .. but i'm not allowed to post outside links
I happened to come across a very interesting article regarding speed improvements for ICS on devices with (TI Pandaboard) OMAP 4430 processors. I believe the NT falls into this category. Supposedly the improvements will practically double the performance of the current build of ICS (4.0.4). The difference is really quite significant. It looks like it is being added to CM9 so we should hopefully see it on the NT!
From what I can gather...
They use a newer compiler and a special toolset built in. The use the linaro android system that has all string operations replaced for a faster build. They changed the way that the build system works. It sounds like the optimization is CPU based, so it should work even if Ducati isn't working. There are a lot of other optimization included, but I didn't really understand what the guy is talking about. You can find a video in the link below.
http://www.androidpolice.com/2012/0...e-and-now-parts-of-it-are-being-added-to-cm9/
https://wiki.linaro.org/Platform/Android
I guess the question is what we need to do to be sure that this gets implemented?
It sounds like some of it is being worked into the CM source. So I'd say we may see some after that unless some one feels like working it into a build themselves.
See the last few posts in this thread.