i'm running on
Nvidia GTX 960 4GB Vram
Intel core i5 6600k
16GB Ram
i got about 20 FPS when run benchmark (Vellamo)
and pic is like everything is shadow except sky
any advice here ?
Currently RemixOS is stuck with the open source NVIDIA drivers (nouveau) so I don't think there's anything you can do to get it to run well on your GPU. The drivers for Intel and ATI/AMD graphics work better, so if you really want to get RemixOS working well you can try using the integrated Intel GPU if your motherboard has the port.
Sent from my iPhone using Tapatalk
putr4s said:
Currently RemixOS is stuck with the open source NVIDIA drivers (nouveau) so I don't think there's anything you can do to get it to run well on your GPU. The drivers for Intel and ATI/AMD graphics work better, so if you really want to get RemixOS working well you can try using the integrated Intel GPU if your motherboard has the port.
Sent from my iPhone using Tapatalk
Click to expand...
Click to collapse
wow Thanks Buddy !!
i think i will wait for it
Nouveau yes, but still
Still I don't get it. The nouveau site says explicitly that they support all nvidia cards. Look at the last news entry from March 2016. They say they have full 2D/3D acceleration. So why don't we have an accelerated desktop in remix os?
It seems u will wait for very long, cause nothing is open for nvidia.
or29544 said:
Still I don't get it. The nouveau site says explicitly that they support all nvidia cards. Look at the last news entry from March 2016. They say they have full 2D/3D acceleration. So why don't we have an accelerated desktop in remix os?
Click to expand...
Click to collapse
By "support" they mean that the basics are working, however just about everything the developers do is based on reverse-engineering, unlike the drivers for Intel graphics, which Intel develops themselves with help from the community, so performance is far from optimal, and sometimes things fail.
putr4s said:
By "support" they mean that the basics are working, however just about everything the developers do is based on reverse-engineering, unlike the drivers for Intel graphics, which Intel develops themselves with help from the community, so performance is far from optimal, and sometimes things fail.
Click to expand...
Click to collapse
But I'm not talking about optimal performance here. I am talking about the decent 30 fps on an operating system that usually runs very fast on systems *much* slower than mine. Again, the nouveau site says they support 2D/3D hardware acceleration for all nvidia cards (since March 2016) - so where's the problem? 2D/3D hardware acceleration doesn't sound like basic support to me.
---------- Post added at 07:02 AM ---------- Previous post was at 07:00 AM ----------
And again - everybody keeps talking about how open intel is. You can't seriously expect me to consider throwing away my graphics card. My assumption is Jide simply did not update their nouveau drivers to the latest (according to the nouveau web site). I wonder how could I do that manually...
or29544 said:
But I'm not talking about optimal performance here. I am talking about the decent 30 fps on an operating system that usually runs very fast on systems *much* slower than mine. Again, the nouveau site says they support 2D/3D hardware acceleration for all nvidia cards (since March 2016) - so where's the problem? 2D/3D hardware acceleration doesn't sound like basic support to me.
---------- Post added at 07:02 AM ---------- Previous post was at 07:00 AM ----------
And again - everybody keeps talking about how open intel is. You can't seriously expect me to consider throwing away my graphics card. My assumption is Jide simply did not update their nouveau drivers to the latest (according to the nouveau web site). I wonder how could I do that manually...
Click to expand...
Click to collapse
I think that might be because the card is running on its lowest performance state, nouveau has the ability to change it but it's not enabled by default. See here: http://www.phoronix.com/scan.php?page=article&item=nouveau_try_linux316&num=1
Note that you'll need to add nouveau.pstate=1 to the boot parameters, and you might need to use the root terminal (Ctrl-Alt-F1 to access, Ctrl-Alt-F7 to go back to desktop). Don't mind the fact that it's for Linux 3.16, the method only changed for Linux 4.5 and newer (RemixOS is still at 4.4.6 last I checked). Anyway, I haven't tried any of this (can't actually, my laptop uses Optimus hybrid graphics switching, which has zero support in RemixOS right now), so good luck.
Ok so I successfully added the nouveau.pstate=1 parameter and checked it via cat /proc/cmdline.
But I simply can't find the pstate file in /sys/class/drm/card0/device
I searched on several forums/articles and they all point to that file...
or29544 said:
Ok so I successfully added the nouveau.pstate=1 parameter and checked it via cat /proc/cmdline.
But I simply can't find the pstate file in /sys/class/drm/card0/device
I searched on several forums/articles and they all point to that file...
Click to expand...
Click to collapse
Check all the drm/card* files; its probably card0-eDP or something
No go
I did find the pstate file in /sys/kernel/debug/dri/0/pstate though - that's the location for the 4.5 kernel which remix os does not have. But when I tried to cat the file it would give me a read error.
I am sorry to keep insisting on this one and I think it's not the proper way to use Remix OS, but I feel a lot of people have nvidia cards and we are all just sitting here and waiting for something on behalf of Jide - and I realize there's not much they can do.
or29544 said:
No go
I did find the pstate file in /sys/kernel/debug/dri/0/pstate though - that's the location for the 4.5 kernel which remix os does not have. But when I tried to cat the file it would give me a read error.
I am sorry to keep insisting on this one and I think it's not the proper way to use Remix OS, but I feel a lot of people have nvidia cards and we are all just sitting here and waiting for something on behalf of Jide - and I realize there's not much they can do.
Click to expand...
Click to collapse
maybe i think i will sell my nvidia gpu
jk lol
Ok so I am not willing to lose hope yet. It's clear to me nouveau is not the way to go. The power states must be changed manually and they won't switch dynamically according to the GPU usage. Basically nouveau is useless at this point. They talk on their forums about the progress they are making - and it's a good effort, but as long as I have to manage the card's power states manually - it's worthless.
So then my other option would be installing the proprietary nvidia drivers. I guess nobody ever did that in remix os...
In linux it's quite easy: you just run the binary file from nvidia and you are more or less done. I could download it and try to install it in remix os but I am pretty sure there are some configuration steps that I would have to do. Anybody have any thoughts?
or29544 said:
Ok so I am not willing to lose hope yet. It's clear to me nouveau is not the way to go. The power states must be changed manually and they won't switch dynamically according to the GPU usage. Basically nouveau is useless at this point. They talk on their forums about the progress they are making - and it's a good effort, but as long as I have to manage the card's power states manually - it's worthless.
So then my other option would be installing the proprietary nvidia drivers. I guess nobody ever did that in remix os...
In linux it's quite easy: you just run the binary file from nvidia and you are more or less done. I could download it and try to install it in remix os but I am pretty sure there are some configuration steps that I would have to do. Anybody have any thoughts?
Click to expand...
Click to collapse
idk
i didn't have knowledge about this thing before
but yeah
i'll wait for good news. and hope you can solve it buddy
nvidia geforce
I have nvidia gefoce 8400gs and enything is fine expect the screen resolution , I dont know how I can change it
or29544 said:
Ok so I am not willing to lose hope yet. It's clear to me nouveau is not the way to go. The power states must be changed manually and they won't switch dynamically according to the GPU usage. Basically nouveau is useless at this point. They talk on their forums about the progress they are making - and it's a good effort, but as long as I have to manage the card's power states manually - it's worthless.
So then my other option would be installing the proprietary nvidia drivers. I guess nobody ever did that in remix os...
In linux it's quite easy: you just run the binary file from nvidia and you are more or less done. I could download it and try to install it in remix os but I am pretty sure there are some configuration steps that I would have to do. Anybody have any thoughts?
Click to expand...
Click to collapse
Hello, so how is this work? On what percentage of progress? Have you got any progress?
Woodraw said:
Hello, so how is this work? On what percentage of progress? Have you got any progress?
Click to expand...
Click to collapse
Yes, I have great progress. I gave up on RemixOS and looked for official alternatives like an officially supported Chromebook by Google and their partners. I bought an Acer Chromebook 14 which will receive the Google Play Store in about a month or so - and if everything goes well, I will switch my main PC with an officially Google supported Chromebox. I had enough tinkering folks. My life is better spent on actually getting things done than trying to force NVidia to write a driver for Remix OS.
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.
Since Xperia S has 2 cores CPU, I think there is sufficient for running desktop OS, like I heard Moto do. So, devs, what about run Linux, or even Windows?
proff_king said:
Since Xperia S has 2 cores CPU, I think there is sufficient for running desktop OS, like I heard Moto do. So, devs, what about run Linux, or even Windows?
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=1582138
Sent from my LT26i using XDA
Windows isn't possible, at least until someone dumps WinRT. Linux is possible as a chrooted system, but there likely will be problems. ICS will bring the 3.0.8 kernel, that might help.
if it virtual machine, i think efficiency of this is rather poor. What I suppoused - get custom ROM, like Android, but change Android (linux-based) to Ubuntu (linux-based), and customize bootloader to choose where to boot. Like i do using grub4 at desktop. My thoughts - my telephone efficient enough, like pentium 4, so i, regarding to Mhz and amount of RAM, can run Win XP like normal desktop based on P4. Amerite?
K900 said:
Windows isn't possible
Click to expand...
Click to collapse
It's posible I've done that .
Erachter said:
It's posible I've done that .
Click to expand...
Click to collapse
Natively? Well show me.
proff_king said:
if it virtual machine, i think efficiency of this is rather poor. What I suppoused - get custom ROM, like Android, but change Android (linux-based) to Ubuntu (linux-based), and customize bootloader to choose where to boot. Like i do using grub4 at desktop. My thoughts - my telephone efficient enough, like pentium 4, so i, regarding to Mhz and amount of RAM, can run Win XP like normal desktop based on P4. Amerite?
Click to expand...
Click to collapse
It's difficult and quite useless.
Emulator.
Erachter said:
Emulator.
Click to expand...
Click to collapse
Oh of course. What was that, 200MHz?
why it is useless? doing so, i can play some old games like diablo 2 or warcraft 2 at my phone, than it would be a low-end laptop, that cost me nothing and always with me at my pocket. my philosophy is to use one gadget for any purpose i wish. no cares of battery, it`s just might do it.
proff_king said:
why it is useless? doing so, i can play some old games like diablo 2 or warcraft 2 at my phone, than it would be a low-end laptop, that cost me nothing and always with me at my pocket. my philosophy is to use one gadget for any purpose i wish. no cares of battery, it`s just might do it.
Click to expand...
Click to collapse
Well go ahead then. I don't think anyone is interested in that, especially considering you won't have telephony, GPU acceleration and likely sound.
Well, if you say so, I understand. And what about Ubunty. I even heard that Ubuntu dev are going to justify multicores CPU at phones with releasing Ubuntu for every 2x or 4x phones. Have you any info about it? Of course, it`s all not about any simulator, just about really booting OS.
proff_king said:
Well, if you say so, I understand. And what about Ubunty. I even heard that Ubuntu dev are going to justify multicores CPU at phones with releasing Ubuntu for every 2x or 4x phones. Have you any info about it? Of course, it`s all not about any simulator, just about really booting OS.
Click to expand...
Click to collapse
Ubuntu for mobile is a long term project that isn't getting released any time soon. And it'll be likely using the Wayland graphics stack, so the same problems apply.
Sent from my EPAD using Tapatalk 2
Not to mention Tegra 3 only match Intel atom 1.6ghz mobile version .
You cant see the CPU power from the ghz and core numbers .
proff_king said:
if it virtual machine, i think efficiency of this is rather poor. What I suppoused - get custom ROM, like Android, but change Android (linux-based) to Ubuntu (linux-based), and customize bootloader to choose where to boot. Like i do using grub4 at desktop. My thoughts - my telephone efficient enough, like pentium 4, so i, regarding to Mhz and amount of RAM, can run Win XP like normal desktop based on P4. Amerite?
Click to expand...
Click to collapse
should be possible. once if got a Native Ubuntu with Dualboot on a HTC Desire HD - the Ubuntu there uses the same Kernel like the Android (was a 2.6.x kernel) - but it needs a lot of Work from a developer that knowns the Device and Linux well to bring it to work.
But also native, a linux will works poor on a Smartphonce, because a Desktop OS is not optimised for Use with fingers - everithing is to small, so you need a pen ore use just the shell.
a VR can be funny, becaus you can install every OS and simulate a x86 architecture.
the Easyest OS is Dos (just install the App Dosbox) - makes fun to play old Lucas Art Games with SCUM Engine again)
I wanted to put a list together to compare results of build times (PLEASE, no fan boys here!). The more info you can list, the better visibility is into the amount of time it takes. I'll start with my machine, what I built and how long it took.
The important parts are processor, ram, operating system, what android os you built, any tweaks you used, and if you have a ssd hdd. And, of course total time! I will list mine in a format for easy reading:
-Sony vaio vgn-nr110
-2gb of ram at 533mhz (upgraded )
-Intel pentium dual core t2310 processor
-running ubuntu at the time. I want to say it was version 10.04(been a while)
-no ssd. Regular laptop hdd
-built cm7 for Optimus s
-used the -j4 flag on make
=approx 4-6 hours (was cleaning while it ran because I knew it would take some time)
Mine was a full build/compile from scratch. Please state whether yours is or isn't, and if you used any special tweaks, etc. Do not include sync time in the total time as that is dependent on the Internet connection and not the machine itself (most people won't, but wanted to have it in here just in case)
My purpose behind this is to get a good idea of what type of system specs perform best with building android roms. If there are any tweaks or tricks that anyone would like to contribute, that would be great too! Please try to stick to the format that I have listed for my machine to make it easier for everyone to read.
As a treat: I will have more results for everyone in a week or two on a new machine.
Amd X2, 2 gb ram, 1tb hdd... Build time 4-5 hours, for cm9 for sprint sgs2, and 3-4 hours cm7
Sent from my SPH-D710 using xda premium
Asus i5 normal HDD 8GB ram
cm9= 65 - 75 min _ simple mka bacon no -j
Cna = 75 - 90 min _ simple mka squish no -j
Aokp = 65-75 min _ simple mka bacon no -j
I try to not have anything else open not even file browser or chrome (usually it will add twenty to forty extra minutes if it's on) although these are my best estimate numbers, time results vary. I use cache and restart Ubuntu before building to let it take the lead over everything else. Building while the PC has been active for over a day seems to always take longer. Aokp has been the record holder for me. Slightly quicker than cm9.
Tcp!? Where you been hiding buddy?
We got you a cake for your birthday but it rusted. We made it out of old Android parts and waited to yell surprise but you never showed. Is you okay? Brb I gotta tweet that I found you on xda! Lol B) good to see you Partna...
Sent from my SPH-D710 using Tapatalk 2
Phenom II X6 2.7GHz, 4 GB RAM, dual 640GB Western Digital Caviar Black in RAID 0.
CM7 for LS670: 18 minutes, 38 seconds. Compile options: make -j12 bacon
Cannibal Open Touch recovery for LS670: 59 seconds. Compile options: make -j12 recoveryimage
HydroKernel for LS670/VM670: 1 minute, 13 seconds. Compile options: make -j12
CM10 for Nexus 7: 48 minutes. Compile options: make -j12 otapackage
Yes it is very important to not have any other programs open (I've even crashed my machine trying to do stuff while compiling with -j12), they will take up more RAM and more CPU time.
Thanks for the responses so far. I hope this can become a list that more people can use as a reference to tweaking their machine for building purposes. I haven't seen any sort of list around and when I do read about the amount of time it takes, I usually see an answer like "it takes however long it takes" which leads to no progress. And at the very least I believe it's cool to see what other's results are.
Sent from my Super Galaxy'd SPH-D710
- Acer 5315
- Intel Celeron M 1,86 Ghz processor
- 1GB Ram
- 80GB HDD
on Ubuntu 10.04 it takes half an hour to compile a kernel with make command without any flag.
I will compile CM7 or ICS when i have free time just for fun to see the amount of time it takes, i guess it will take 22-24 hours
I am planning to change my laptop, this thread will be a good reference for me.
Core i3 2120 3.3ghz
Gigabyte Z68 mobo
8gb 1600 ram
Ubuntu 12 installed on a 100gb partition with 8gb swap on a Seagate Green (5900rpm) 1Tb DRIVE takes about 90 minutes to build CM9 for my Sensation.
I ordered a 120Gb OCZ Agility 3 SSD from tiger for $85 hopefully that will cut the time down significantly.
Sent from my Sensation using xda premium
AMD 3GHZ FX8120 Bulldozer Black Edition ;
16GB (1600) DDR3 ;
7200rpm 1TB HDD ;
Not Sure about the Motherboard without checking.
Linux Mint 13 ( 64 Bit )
EDIT: New build times.
aosp android-4.1.1_r4 ; removed previous out directory
full_panda-eng ; make -j12 49m6.429s
reboot
full_stingray-eng ; make -j16 32m47.270s
It came in around 38 minutes on a intial build of ICS time using make -j16.
Lately It's a little longer and I've been unable to get some fresh times because I don't have great cooling and it kept overheating and resetting because of hot whether.
It can be clocked to 5GHz with proper cooling and an SSD would bring the time down, I think, but given some reported times I am more than happy with that as it means I don't have to think twice about (re)building a rom.
In testing however I think this processor did fairly poor especially when up against similar Intel and looking at the couple of Intel times here I'd say they're the ones to go with.
Notes:
I always restart before building, I found it vital to restart after a repo sync as there seems to be a memoy leak in either repo or python, I don't know whether that has been fixed yet.
Incidentally I did Start a build on an Ubuntu VM which had 3 CPU Cores assigned and 4GB Ram, It was still going after 2 Days!
trevd said:
AMD 3GHZ FX8120 Bulldozer Black Edition ;
16GB (1600) DDR3 ;
7200rpm 1TB HDD ;
Not Sure about the Motherboard without checking.
Linux Mint 13 ( 64 Bit )
Incidentally I did Start a build on an Ubuntu VM which had 3 CPU Cores assigned and 4GB Ram, It was still going after 2 Days!
Click to expand...
Click to collapse
that doesnt seem right! lol.. really? not 2 whole days?
justlovejoy said:
that doesnt seem right! lol.. really? not 2 whole days?
Click to expand...
Click to collapse
Yep, You read it right lol. I went out for the weekend and when I came back it was still going I forget to add it was a dynamically sizing virtual disk which probably will account for it.
trevd said:
Yep, You read it right lol. I went out for the weekend and when I came back it was still going I forget to add it was a dynamically sizing virtual disk which probably will account for it.
Click to expand...
Click to collapse
That was with virtual machine right? Have u tried using ccache on an install of ubuntu yet?
Sent from my Super Galaxy'd SPH-D710
basketthis said:
That was with virtual machine right? Have u tried using ccache on an install of ubuntu yet?
Sent from my Super Galaxy'd SPH-D710
Click to expand...
Click to collapse
Yeah, like I put the Ubuntu VM ( Virtual Machine ). That's the day I learned to build on proper hardware, I tried the VM because I was on a later Ubuntu at the time and had run into a couple of issues so I wanted to follow google's aosp instructions to the letter and rule any versioning issues out..... schrooting is a much eaiser way of using a previous disto versions binaries, this is a great article on how build android using schroot. Good If you've ever get an urge for a cupcake or a donut one day
I do use ccache, but thanks for asking. Set in the bash profile so I never forget . Not looked into whether it should be cleared down at any point, I am on a 500GB partition though so I've not hit any limits yet.
trevd said:
Yeah, like I put the Ubuntu VM ( Virtual Machine ). That's the day I learned to build on proper hardware, I tried the VM because I was on a later Ubuntu at the time and had run into a couple of issues so I wanted to follow google's aosp instructions to the letter and rule any versioning issues out..... schrooting is a much eaiser way of using a previous disto versions binaries, this is a great article on how build android using schroot. Good If you've ever get an urge for a cupcake or a donut one day
I do use ccache, but thanks for asking. Set in the bash profile so I never forget . Not looked into whether it should be cleared down at any point, I am on a 500GB partition though so I've not hit any limits yet.
Click to expand...
Click to collapse
Setting up a box with the same processor. I expected to see better than 30 min builds for ICS. I will see what I come up with.
I am guessing that you were on windows and that's why you chose to go with virtual machine?
I have also read that different file systems read i/o faster/slower than others. Reference
Sent from my Super Galaxy'd SPH-D710
basketthis said:
Setting up a box with the same processor. I expected to see better than 30 min builds for ICS. I will see what I come up with.
I am guessing that you were on windows and that's why you chose to go with virtual machine?
I have also read that different file systems read i/o faster/slower than others. Reference
Sent from my Super Galaxy'd SPH-D710
Click to expand...
Click to collapse
Maybe on JellyBean, On ICS i'm not so sure about, From my very casual observations JB seems to be use a lot less ram in it build process, ICS always just touched swap from a start of about 15GB .
Like I mentioned earlier, from the reviews I read the processor is out perfomed by similar intels and a bit a flop apparently. ( I reads these reviews long after I had bought the processor ). Although I'm happy enough with it. Also I've only got a generic kernel installed so there's probably some AMD optimization to be had there if I really wanted to get into it.
I wasn't on windows at the time. I was just young, foolish It was when I was just getting started with building the sources and really didn't know any better....I still am foolish, just not as young.
Right, I'll be back in ( just over ) 30 mins :laugh: I've got a full_grouper-eng to compile.
Thanks for the link, Phoronix are a really useful resource, It's one I stumble upon now and again but always forget the name of it when I want to remember.
Using virtual box on my laptop at the time I was solo boot on windows, longest cm9 ever took was about 3 hours with dynamically resizing and was using two cores with less than 2 GB ram. Still, many things differ, I shut the whole thing down so only virtual box was running. I noticed lag when I would go web browsing so figured, why waste ram and disk space.
Sent from my SPH-D710 using Tapatalk 2
trevd said:
Maybe on JellyBean, On ICS i'm not so sure about, From my very casual observations JB seems to be use a lot less ram in it build process, ICS always just touched swap from a start of about 15GB .
Like I mentioned earlier, from the reviews I read the processor is out perfomed by similar intels and a bit a flop apparently. ( I reads these reviews long after I had bought the processor ). Although I'm happy enough with it. Also I've only got a generic kernel installed so there's probably some AMD optimization to be had there if I really wanted to get into it.
I wasn't on windows at the time. I was just young, foolish It was when I was just getting started with building the sources and really didn't know any better....I still am foolish, just not as young.
Right, I'll be back in ( just over ) 30 mins :laugh: I've got a full_grouper-eng to compile.
Thanks for the link, Phoronix are a really useful resource, It's one I stumble upon now and again but always forget the name of it when I want to remember.
Click to expand...
Click to collapse
Build a kernel
There are fx flags and optimizations....
Edit: If on ubuntu/Linux, you may want to check that your os is recognizing more than 3gb of ram also. I've been reading that anything newer than ubuntu 10.10 or Linux kernel 2.3.something are having issues with recognizing more than approx 3gb of ram. Also, there are issues with 10.04 and optimizations of ssd drives.
Also, I think it was 10.04 that is recognized as the better ubuntu version for building android. It is possible to use a newer (3.0+) kernel and back port it to the older ubuntu. This seems to give the best results...
Putting this info here for reference and to have it in a central location.
Lol, I've read many reviews. I am trying my hardest to keep any opinions out of here and keep it geared toward facts. It appears that Linux is better at multi-threading and we should expect to see gains when building a custom kernel (non-generic) and other things to come in the future. Whereas windows will need much more tweaking. Although I don't know why you would use windows to build android anyway....
Sent from my Super Galaxy'd SPH-D710
Takes about 20m on my pc, i7-2600K, 12GB, 7.2K HDD
real 20m14.526s
user 74m51.913s
sys 4m53.774s
^full-eng from clobber, same for other targets.
cdesai said:
Takes about 20m on my pc, i7-2600K, 12GB, 7.2K HDD
real 20m14.526s
user 74m51.913s
sys 4m53.774s
^full-eng from clobber, same for other targets.
Click to expand...
Click to collapse
I really must be missing a trick here and clearly haven't spent enough time on my considering the finer details of my hardware / kernel configuration.
basketthis said:
Build a kernel
There are fx flags and optimizations....
.....
Edit: If on ubuntu/Linux, you may want to check that your os is recognizing more than 3gb of ram also. I've been reading that anything newer than ubuntu 10.10 or Linux kernel 2.3.something are having issues with recognizing more than approx 3gb of ram
...
Lol, I've read many reviews. I am trying my hardest to keep any opinions out of here and keep it geared toward facts. It appears that Linux is better at multi-threading and we should expect to see gains when building a custom kernel (non-generic)
Sent from my Super Galaxy'd SPH-D710
Click to expand...
Click to collapse
Current Config is Linux Mint 13 x64 which is based off Ubuntu 12.04 with 3.2.0.26 kernel the Ram is Present and correct, However I have come across the 3GB Ram Limit previously so I am familiar with it. I think I must have been I had an 11.04 32bit on my machine.
PAE Extensions is the feature which needs enabling to get your full quota of ram on 32bit. Here's is an Ubuntu Help Page which gives a good explaination if any one is interested
I think there is some research followed by a rebuild on my horizon Thanks for the suggestions and the thread It's proving educational. I'll let you know how I get on, at the very least post some new build times
EDIT / UPDATE
I did some research and made some tentative first steps with my Kernel Configuration.
I decided to get on the mainline and build a 3.6-rc1. I removed a number of options I know to be redundant In my case, e.g Laptop Support, Intel Support etc
My research did throw up this Gentoo Wiki With Some useful "copy/pasta" compiler optimization, they also have a more in depth guide here.
After building this new kernel and clobbering my aosp tree I did
full_grouper-eng for JRO03L and a
make -j10 which resulted in
real 49m32.493s
user 312m45.481s
sys 17m55.599s
While this is still high, it's a step in the right direction, The times are around the same length I was getting for a full_panda with -j12 previously. I'll do a direct comparison also, Kinda Makes sense
I got quiet a lot of room for Improvement and many options, Only Clock at 2.8Ghz at the Moment.
AMD Provide an FX Bulldozer Specific GCC Toolchain which Is going to be employed when the I Rebuild the Kernel again
I Plan to tweak a bit, test a bit and see If I can get the performance some where close and hopefully learn some tricks along the way If all else fails I'll Surmerge the lot in a fishtank full of cooking oil and clock it to 5GHz
UPDATE 2
Following on from the Build Above -
Full_panda-userdebug make -j16
real 32m16.986s
user 196m34.933s
sys 13m9.521s
full-eng
aosp jellybean
fx-8120, 8gb ram, 8gb swap
make -j16
real: 34m2.641s
EDIT: about to test some tweaks! will update.
Machine: Dell Inspiron 1565
Processor: Intel Core 2 Duo 2.0GHz
Hard Drive: 320GB HDD
RAM: 4GB
OS: Ubuntu 11.04
Current Build Time: 2 1/2 +
Build: CM10 PA Source
Just added ccache. We will see on the next build if I shave some time.
I have this MB under the desk and a lot of dust!!..
and i have an idea....
I want to make a little and complete HTpc with android.
The idea is:
-2 disk in raid 1 for a "NAS"
-1 disk SSD to install system
-Android to use a lot of app like kodi, youtube, netflix
-DVBT2 for see TV
All with 1 device, 1 remote control.
Simple and User friendly
A little problem, with this alpha does not start.
I try phoenix os, and i have a loop crash of the GUI
Anyone has got this MB to share the test?
Thanks!
fringui said:
I have this MB under the desk and a lot of dust!!..
and i have an idea....
I want to make a little and complete HTpc with android.
The idea is:
-2 disk in raid 1 for a "NAS"
-1 disk SSD to install system
-Android to use a lot of app like kodi, youtube, netflix
-DVBT2 for see TV
All with 1 device, 1 remote control.
Simple and User friendly
A little problem, with this alpha does not start.
I try phoenix os, and i have a loop crash of the GUI
Anyone has got this MB to share the test?
Thanks!
Click to expand...
Click to collapse
I have a few of the Zotac Mag NDo1 lying around and wanted to try Remix on also, same CPU/GPU combo, hopefully will get time this weekend to test. I'll keep you posted on my results.
adfurgerson said:
I have a few of the Zotac Mag NDo1 lying around and wanted to try Remix on also, same CPU/GPU combo, hopefully will get time this weekend to test. I'll keep you posted on my results.
Click to expand...
Click to collapse
Perfect
I'm not alone!!
I want to try to do a RAID 1 and try to use from android...
I hope in the next alpha.. o beta...
fringui said:
Perfect
I'm not alone!!
I want to try to do a RAID 1 and try to use from android...
I hope in the next alpha.. o beta...
Click to expand...
Click to collapse
Well if you know how to set up storage controllers you are way more advanced user than I am. I am half decent at searching stuff though, the problem I have now is information overload.
If you add this to the grub boot menu it is supposed to help run nvidia graphics.
nouveau.modeset=1 i915. modeset=0
Another bit of info is the 330 is underclocked 2.0 is native speed, believe this was done to save battery in netbooks.
Nothing but fail on my end, I even failed to get it to boot on my desktop.
Edit....double post. Why is there an edit/delete button but I can't find a way to delete a post?
adfurgerson said:
Nothing but fail on my end, I even failed to get it to boot on my desktop.
Click to expand...
Click to collapse
Same, only got it working in guest mode on my laptop with intel graphics. Resident mode did not work and my atom 330/ion combo just flat out refused to boot.
gunzy83 said:
Same, only got it working in guest mode on my laptop with intel graphics. Resident mode did not work and my atom 330/ion combo just flat out refused to boot.
Click to expand...
Click to collapse
I finally got it booting from a SSD in an external enclosure on my regular desktop. If Jide doesn't offer any better support for nvidia I will probably look around on the ark.Intel site and see if there is another atom processor that will fit in motherboard socket. I couldn't imagine one costing much on eBay.
We are in the 2nd alpha.. it's impossibile to work on all platform!
fringui said:
We are in the 2nd alpha.. it's impossibile to work on all platform!
Click to expand...
Click to collapse
Switching the CPU isn't a possibility from what I have read. There is update that is just released, also I want to try the 32 bit for the heck of it. Linux can be ran on the 330/ion combo, so it makes me wonder if there is still hope.
On the latest beta on zotac work!!
Now i try to use and test... thanks!
I have a nexus 9 wifi 16gb and its terrible. I mean, it can't run more than 1 app at a time! All I use it for is reading documents and browsing and most of the time I don't even do them simultaneously, but have to read multiple documents by switching and even for that it doesn't work! It reloads the other app every single time I switch!
I read a few people asking to try custom ROMs for RAM issues, and right now I'm on official lineage os 14.1. Its quite better than stock, but still terrible.
It takes 1.7gb RAM on average out of available 1.8 (for above mentioned usage).
So after reading all about android Oreo go edition and their stupid idea to bring back cheap phones with 1gb ram or less (seriously? To prove that your OS can run on it?), finally I think go edition can bring dead devices like this back to life. So "is it possible to run go edition on nexus 9 and if so, when?" is what I want to know.
And by the way, don't ask me to stop using chrome and other apps. Chrome hardly even takes 50mb of ram on average I also tried uninstalling it. Not much of a difference. I've already seen many ROM recommendations but still any highly recommended suggestions are entertained.
I would actually be willing to give this a try. May breathe new life into my old Nexus 9.
Until now the source code of Android go hasn't been released yet, so we will need to wait for that. When it's released I'm sure someone will give it a try
Go really isn't the issue. If you want to be faster, either run that ported 32bit kernel or run fire and ice or elemental x and change the settings. And no encryption. And perhaps most important, run pure Nexus as it runs better than anything I've tried.
sprockkets said:
Go really isn't the issue. If you want to be faster, either run that ported 32bit kernel or run fire and ice or elemental x and change the settings. And no encryption. And perhaps most important, run pure Nexus as it runs better than anything I've tried.
Click to expand...
Click to collapse
OK I'll give it a try. By the way, do you know any other devices for which the 32 bit kernel is ported(maybe a thread link)? I need it for my redmi note 3 since I believe 32 bit software requires less resources to run overall, leaving more RAM for user apps. This is probably the reason why my oneplus one still works pretty well in RAM management section.
sprockkets said:
Go really isn't the issue. If you want to be faster, either run that ported 32bit kernel or run fire and ice or elemental x and change the settings. And no encryption. And perhaps most important, run pure Nexus as it runs better than anything I've tried.
Click to expand...
Click to collapse
Why do you say that Go won't help? The whole point of Go is to run on crappy hardware like the Nexus 9.
KevlarTheGreat said:
Why do you say that Go won't help? The whole point of Go is to run on crappy hardware like the Nexus 9.
Click to expand...
Click to collapse
Because the Nexus 9 isn't by definition typical crappy hardware. It has 2GB of RAM and it has a "fast" CPU.
The problem is, is that it has a fundamentally different architecture than normal android. You can watch it update and install apps very quickly then take forever to open up a normal app. That's due to how that ridiculous CPU works.
Heck, since all the apps can be installed without the OS you might as well try that.
KevlarTheGreat said:
Why do you say that Go won't help? The whole point of Go is to run on crappy hardware like the Nexus 9.
Click to expand...
Click to collapse
Since when does n9 have crappy hardware? Lol. We all know what the n9's performance issues stem from, and it's not "crappy" or "cheap" hardware. It's a programming language (or CPU language) issue.
Just like @sprockkets said.
Have you tried the 32bit AOSP build? It really helped with RAM management. I can switch to multiple tabs in chrome now without it having to reload every time. Too bad it hasn't been updated lately
madbat99 said:
Since when does n9 have crappy hardware? Lol. We all know what the n9's performance issues stem from, and it's not "crappy" or "cheap" hardware. It's a programming language (or CPU language) issue.
Just like @sprockkets said.
Click to expand...
Click to collapse
Haha, what are you talking about? The programming language used for Android on the Nexus 9 is the same as the programming language for every other version of Android (mostly C, C++, and Java). It's just Android.
CPU language... do you mean the CPU instruction set? The NVIDIA Tegra K1 is a ARMv8-A CPU. ARMv8-A is a 64-bit architecture. It's true that when the Nexus 9 launched 64-bit devices were uncommon, so there were some compatibility issues. But that's far in the past. Every Android device from 2015 and on has a 64-bit CPU. The Nexus 6P, Nexus 5X, Pixel, and Pixel 2 all have ARMv8-A CPUs.
sprockkets said:
Because the Nexus 9 isn't by definition typical crappy hardware. It has 2GB of RAM and it has a "fast" CPU.
The problem is, is that it has a fundamentally different architecture than normal android. You can watch it update and install apps very quickly then take forever to open up a normal app. That's due to how that ridiculous CPU works.
Heck, since all the apps can be installed without the OS you might as well try that.
Click to expand...
Click to collapse
Android Go is not fundamentally different from Android. It's just a stripped down version of Android intended to run on less powerful hardware. Things like multi-tasking and animations are disabled. Android Go is a variation of Oreo. The official name is Android O (Go edition). There will be an Go edition of Android N as well. Google created it to encourage entry level devices to run Oreo rather than some old version of Android as is common in developing countries.
---------- Post added at 04:03 PM ---------- Previous post was at 04:03 PM ----------
As sprockkets said, you can install the Google's (Gmail, YouTube, Maps, etc.) Android Go applications from the Play Store on non-Go devices. Additionally, you can flash this Low-RAM Property Patcher. It sets the flag that tells apps and the The Play Store that you have low RAM. I don't think many apps use this flag right now. But if Go devices become popular, developers may disable some the more memory intensive features (animations for example). Now if you are running Oreo, this will also cause the Android UI to use less RAM.
Although there is at least one Oreo ROM for the Nexus 9, I don't expect them ever to be stable. There are no Oreo drivers for the NVIDIA Tegra K1. And it's doubtful there ever will be. You could ask that developer to build a Go version of the ROM. It may make a difference.
benpage said:
Haha, what are you talking about? The programming language used for Android on the Nexus 9 is the same as the programming language for every other version of Android (mostly C, C++, and Java). It's just Android.
CPU language... do you mean the CPU instruction set? The NVIDIA Tegra K1 is a ARMv8-A CPU. ARMv8-A is a 64-bit architecture. It's true that when the Nexus 9 launched 64-bit devices were uncommon, so there were some compatibility issues. But that's far in the past. Every Android device from 2015 and on has a 64-bit CPU. The Nexus 6P, Nexus 5X, Pixel, and Pixel 2 all have ARMv8-A CPUs.]
Click to expand...
Click to collapse
That is what I meant, ya got me being in a rush, lol.
I meant the difference in nvidia's. As opposed to Qualcomm.
Not between armv7 and armv8
Trying not to get too long winded but...
Perhaps the critical point in understanding Denver then is that it is non-traditional for a high-performance CPU due to its lack of OoOE hardware, and for that reason it’s a CPU unlike any of its contemporaries. We’ll get back to the software aspects of Denver in a bit, but for now it’s enough to understand why NVIDIA has not pursued an OoOE design and what they have pursued instead.
benpage said:
Haha, what are you talking about? The programming language used for Android on the Nexus 9 is the same as the programming language for every other version of Android (mostly C, C++, and Java). It's just Android.
CPU language... do you mean the CPU instruction set? The NVIDIA Tegra K1 is a ARMv8-A CPU. ARMv8-A is a 64-bit architecture. It's true that when the Nexus 9 launched 64-bit devices were uncommon, so there were some compatibility issues. But that's far in the past. Every Android device from 2015 and on has a 64-bit CPU. The Nexus 6P, Nexus 5X, Pixel, and Pixel 2 all have ARMv8-A CPUs.
Click to expand...
Click to collapse
The K1 runs ARMv8 code but if you look at the history of that CPU, you'd realize it was originally made to run x86.
And I'm not really interested in posting the rest of the details - read it for yourself here.
https://www.anandtech.com/show/8701/the-google-nexus-9-review/4
And read pages 2 and 3 for more info, but page 4 has the biggest reason for its wonky performance.