Slashdot Mirror
The Care and Feeding of the Android GPU
bonch writes "Charles Ying argues that Android's UX architecture has serious technical issues because, unlike the iPhone and Windows 7, Android composites the interface in software to retain compatibility with lower-class devices. Additionally, Android runs Java bytecode during animation, and garbage collection blocks the drawing system. Google engineers dismiss the desire for hardware-accelerated compositing and cite more powerful hardware and an avoidance of temporary objects as a solution to the collection pauses, but Ying argues that will just lead to [a lower] average battery life compared to devices like the iPhone."
the interface never seems as polished without hardware acceleration, Just look at Mesa and a full linux desktop running ATI or Nvidia drivers with compiz.
Look at Samsung's Galaxy S browser. GPU accelerated and tile-based. I’m told it’s a result of Samsung’s PowerVR GPU optimizations.
Doesn't that require that the device have a PowerVR GPU on board? What about devices without PowerVR like the NexusOne, does it run on that?
When you optimize to GPUs, you have to optimize to all GPUs. I realize there are common instruction sets but the main selling point of Android is its versatility. If I start coding for only Snapdragon processors with PowerVR GPUs because it has a better UX, then it sort of destroys any benefit I get from Android and I might as well code for iOS because I know what that hardware will always be. A lot of the benefits of Android applications being Java byte code completely independent of the hardware are overlooked in this proposition.
The developers don't know what future devices are going to use for GPUs or their instruction sets. From one of the links Romain says:
New devices might allow us to overcome the past limitations that made GPU support a not-so-good solution.
Doesn't optimization for particular hardware exacerbate their issues with fragmentation?
Well, it's open source, there's always the smug answer that Charles Ying can go fork Android himself and add this and watch all the handset manufacturers flock to his side. If you think it's best, get a team together and do it.
From Ying's article:
Wake up, Android team. Windows Phone 7 just lapped you.
Can anyone tell me why that AnandTech article from March is evidence that Windows Phone 7 has lapped Android? And why it just happened?
My work here is dung.
There is this new thing called "conditional compilation" which allows one to include code that both optimizes for certain hardware and contains generic code that could work on all devices. I hear it's the new rage of how you make code work on multiple hardware and software platforms.
Can anyone tell me why that AnandTech article from March is evidence that Windows Phone 7 has lapped Android? And why it just happened?
He's talking about the fact that Windows Phone 7 has advanced GPU acceleration built in from the beginning in several facets of the environment. Android doesn't and it's a few years older.
It certainly hasn't lapped it in terms of sales or momentum, but it could. Android has both the advantage and the curse of being more open and versatile - WP7 has the possibility of a more restrained set of hardware differences and can build in more low-level functionality.
Because it's not bad at all. A shoddy workman blames his tools.
Website Hosting
I don't know enough about the Android graphics API, but if it's designed properly it should be possible for the client to always call the same function and the underlying implementation to select the code path most optimized for the platform. Mac OS X has one CoreGraphics API, and it either composites on the GPU or on the CPU depending on what's available. I don't see why Amdroiid can't do the same.
Don't blame me, I voted for Baltar.
until the iphone came around RIM and others would have low end, mid and high end devices with different hardware. i've even seen dumb phones run java. it allowed hardware makers to have a ton of devices out there for every niche and cut down on dev costs. Java was cool since you only write the app once.
then the iPhone came and killed that model. the cost of the iphone is something like $2200 over 2 years. Droid is about the same. any other smartphone on AT&T or VZW will be within $200. i tell people to get the best phone they want since the cost is negligible over 2 years.
OS X uses llvm just-in-time compilation in the graphics stack. If the hardware supports it, it's sent to the GPU. Otherwise, it's done in software. Since android is based on dalvik, they shouldn't have a problem doing something similar. Sure, they need to support cheap pieces of shit, but that doesn't mean they can't support anything else.
Do you even lift?
These aren't the 'roids you're looking for.
You mean it's like a real, honest to goodness, computer operating system? Oh no! The horror! Guess you should stop making software for Windows, Linux, and OSX then, since the hardware can provided different capabilities for systems using the same operating system!
You don't need to optimize for all of them. Go ahead and pick some of the more popular ones that already exist and optimize for those. Manufacturers are still free to choose different hardware or write their own code, which they are perfectly free to do being that Android is open.
Having a few 'better' options isn't going to be worse than the lowest common denominator crap that's going on now.
OMG Android is making a play that's designed to let lower cost, highly capable devices subsist in the marketplace? How horrible is that?
I switched from Evil Major Network (TM) to Metro PCS a little over a year ago, and haven't regretted it for a SECOND. It is so nice, getting what you paid for, rather than wondering how much you'll be overcharged for what you aren't even sure you got... it's the ONLY way to survive teen children!
And even Metro PCS, the low price leader, offers a couple of Android phones that are highly capable and useful. For less than $300 I was able to upgrade my wife's shatty phone with a nice, capable Android phone with GPS, navigation, browser, email, games, full-screen youtube, Facebook, Marketplace et al (AKA "the works") and a good, full day of battery life. She LOVES the phone! In case you are wondering, it was the Samsung LG Optimus. And the network cost went from $40/month to (gasp!) $50...
Talk about having your cake and eating it too?
Say what you want, Android's strategy is working, as demonstrated by its continuing skyrocketing market share.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Somebody should really invent a programming interface for graphics. You could use hardware or software rendering for the same code, or generally a mixture of both, depending on the capabilities. It could be called "open graphics library" or something.
Escher was the first MC and Giger invented the HR department.
Debian seems to handle it just fine and (based on gcc) they're compiling for 14 different platforms* and 3 different kernels (linux, hurd, freebsd)
Is it that difficult to setup a similar thing in the app store? "Oh it looks like you're running an ARMv5 and a PowerVR GPU. We'll give you this binary."
Or, you do what Apple has always done with Fat Binaries. 68k to PPC. PPC to PPC64. PPC* to i386. i386 to x86_64. You could have one single fat binary that supported ppc, ppc64, i386 and x86_64. And it "Just worked". They were literally checkboxes in XCode. How many GPU and CPU solutions are there for the Android? This isn't low level Assembly code, it's compiled Java.
*alpha amd64 armel hppa hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mipsel powerpc s390 sh4 sparc sparc64
Let me tell you one thing about that: Java isn't the problem. In my definition of feeding the GPU: triangles/sec, fillrate and OpenGLES objects/sec, Java is just 10% behind a raw C benchmark like glbenchmark 1.1/2.0. They quoted 880kT/s, I managed 750kT/s in non native code. And to get that, you have to carefully feed the GPU with the right batch sizes, don't issue too many state changes, pack things interleaved in the video buffer, don't use dynamic point lights, etc etc. It isn't as bad as an NDS, but the Snapdragon GPU is quite hard to tame.
The problem with using the GPU is that every context switch requires a complete reinitialization of the GL context, even on a PC, alt tabbing into and from fullscreen games takes ages - it's fine when specific applications which requires the speed use it directly, but it's not when going from one activity to another gives you a loading screen.
Animation performance and touch responsiveness? Is that the best he can come up with for such a title? I have no idea what he's talking about, but scrolling the browser works just fine here on a not-so-recent HTC Desire. The only time things break down is when the garbage collector halts everything for a third of a second (see DDMS/logcat messages), and those pauses are reduced to sub 5ms in the new builds. That's tons more useful than rendering surfaces to quads and using OpenGL ES to draw them, and IMO, the Android team made the right decision.
That depends on the optimization and how that chipset actually handles throwing stuff on the screen. 'Optimize' may not just mean "format the data this certain way and it'll fly through the processors more quickly", it could also mean "use more polygons and lower-res textures because the chipset is better at moving verts around than filling texels". It doesn't matter that it's not low-level if it affects how the whole engine works.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
Add to that, you really don't need to optimise the code that you use for compositing on the GPU. A low-end mobile GPU can render something on the order of three million textured triangles per second. A typical mobile UI has a few dozen UI elements, with one texture and two triangles (one square) each. Even really crappy code is not going to come close to taxing the GPU. That's why we do compositing on the GPU - because it can run in its lowest-clocked mode and still provide fast performance, which lets you use the CPU for something else (or down-clock it too and save battery life).
I am TheRaven on Soylent News
The language itself has 0 to do with its speed. As for the JVM, well Android uses the Dalvik VM. As for whether or not it is fast, there is really no technical reason it would be any slower than any other byte-code interpreter (eg. .NET). So, given that, I take it you have a problem with any sort of bytecode, preferring only natively compiled software? That kind of goes against the hardware agnostic nature of Android, doesn't it? What would you suggest that an OS, whose major feature is cross-device compatability, do?
massively different user experience on different devices
consider: different user experience on massively different devices
Why should it be otherwise? Should a quad-core i7 SLI provide exactly the same 'user experience' as an Atom netbook? Obviously not. It is not reasonable to expect the same results from increasingly diverse hardware. Android will be found on the lowest end freebee 'smart' phone China can make, while also appearing on the most outrageous hardware that doesn't present an immediate fire hazard. Where, exactly, was it written that the limits of one must apply to the other?
This problem has been solved over and over again. An architecture must exist that provides fall-back software implementations of hardware accelerated functions. When some app performs poorly due to inadequate hardware the user may find some other preoccupation or upgrade to a sufficient device.
What is the problem? At the moment it appears to be Google's obstinacy. This is a losing battle for them; they're creating a differentiating point among the manufacturers because the manufacturers can alter Android, including accelerating stuff with hardware. Marketing will then make claims about how xyz's Android is better than the other Androids because of xyz's special sauce (that may or may not port easily to some other collection of chips.) If the manufacturers don't the users will.
Lets hope Google wises up and deals with the issue properly.
Lurking at the bottom of the gravity well, getting old
At least a sledgehammer is an actual hammer. Using Java on a mobile devices is more like using a whale to hammer in screws.
Speaking as a former Googler, the smart people spin is somewhat overrated. Arrogant people is closer to the truth, and "smart" tends to mean "good at avoiding work".
Have you got your LWN subscription yet?
All the expensive devices uses capacitive screens, nice multitouch ones too.
Resistive is usually the cheap kind.
If one is incapable of writing Java/Dalvik code that runs well then I pitty the C code they will churn out.
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
And you say that as an unbiased observer with no axe to grind, right? :-)
Right. I still own all my Google shares. However I am now properly disillusioned about a number of Google myths, but don't trust me. Ask any Googler, former or otherwise. In the latter case, make sure to do it out of earshot of other Googlers.
There are smart people at Google, and if they are really smart they learn early to keep their heads down. This seems to be the main sequence for large tech companies. Microsoft is far advanced on that path and Google seems more than a little determined to follow. The stack ranking system is nearly a carbon copy of Microsoft's, which in turn was copied from GE, and look how well that worked out. The result is inevitable degradation of the engineering culture. Now, warning about the negative consequences is not the same as axe grinding, quite the opposite.
Have you got your LWN subscription yet?
But how is that any different than the massively different user experience between the iPad and a Touch and an iPhone 4? Rovio's popular Angry Birds game has more choppy animations on the iPad than on some of the unsupported Android devices, btw.
Interesting theory. I've been working with Java since version 1.0 on devices as slow as an embedded 100Mhz device with 128MB RAM and I never remember GC taking seconds.
Just because I'm curious I tried to push our Java application (Data integration engine) to use both CPUs at 100% and dump the Garbage Collection stats to disk. Here's a typical sample:
133,091: [GC 30567K->10559K(60160K), 0,0052000 secs]
133,447: [GC 34943K->10347K(64832K), 0,0036360 secs]
133,873: [GC 39659K->10347K(63872K), 0,0028940 secs]
134,286: [GC 38699K->10531K(63104K), 0,0033140 secs]
134,674: [GC 37923K->10263K(61952K), 0,0019690 secs]
135,072: [GC 36759K->10351K(61184K), 0,0024490 secs]
135,462: [GC 36015K->10339K(60352K), 0,0022610 secs]
135,797: [GC 35171K->10739K(59840K), 0,0039780 secs]
136,134: [GC 34803K->10679K(59008K), 0,0033120 secs]
136,479: [GC 33975K->10567K(58048K), 0,0029140 secs]
136,801: [GC 33159K->10647K(57472K), 0,0026420 secs]
Note that this is without incremental garbage collection enabled. It might be possible for graphics intensive applications to notice the fraction of a second of delay but something tells me that this just might not be the case.
News about the Kettle Open Source project: on my blog
Additionally, Android runs Java bytecode during animation
Except in the real world, where Android uses a non-Java VM with its own bytecode, and doesn't run Java bytecode at all.
There's a myth going around that battery life is strongly affected by how efficient your code is. On most phone, it's simply not true. By far the biggest power drains are the screen and the radios (cellular, wifi, bluetooth). On Android, there's even a handy battery monitor built in that you can use to confirm this (Settings->About phone->Battery use). I can spend half an hour playing a high end, graphics intensive game (Hero of Sparta) on my Nexus One, and when I then check the battery use, I find that even while I was playing the screen and the cellular radio standby were still the dominant uses of power.
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
I think your joke went over most people's heads (your post is modded Insightful instead of Funny). For those who are wondering, the answer is OpenGL.
Ahem...
Add to that this... Most SoC's run a fairly narrow and slow memory bus. Also, GPU's tend to be WAY slower than CPUs...
Fancy racing a 4 * 150Mhz pipe GPU against a 1 Ghz, superscalar CPU with 64/128 bit SIMD extensions?
Who will win?
Answer... the memory bus. You can TRY and get the CPU and GPU to work together but all that will happen is that the memory bus will get swamped and everything slows down.
GPUs can render polys with straight edges. UIs frequently want curved, rounded objects with complex gradients and complex blend modes not supported by GPUs.
TBH the article is nonsense. Android composites using OpenGL. Individual applications render with SKIA for 2D. The SKIA API is deliberately immediate mode to reduce latency (GPU's do not multitask and have rubbish MMUs). All applications are back buffered so they cache bitmaps pretty well. Bitmap copying is minimal.
Maybe a scene graph would help - but you'd increase latency greatly and (if GPU accelerated) you'd make the GPU task switch - not quick on many (most) GPUs.
Also - Poly throughput isn't the problem - fill rate is... (see Memory Bus above).
Burnttoys.
Time flies like an arrow. Fruit flies like a banana.