The Care and Feeding of the Android GPU
satine.org
The Care and Feeding of the Android GPU
1–10 of 60 posts
Re: The Care and Feeding of the Android GPU
#2This isn't the first thing I've seen that Google devs really just didn't get. I think it's from the rapid expansion that Google has done. They get people working on things that aren't really their area of expertise because they wanted to try something in their 20% time.
In this case, it's obvious that we've got server people working on mobile code. Future hardware will resolve these inefficiencies? UGH. That's definitely someone from the server world speaking.
Re: The Care and Feeding of the Android GPU
#3This isn't the first thing I've seen that Google devs really just didn't get. I think it's from the rapid expansion that Google has done. They get people working on things that aren't really their area of expertise because they wanted to try something in their 20% time. In this case, it's obvious that we've got server people working on mobile code. Future hardware will resolve these inefficiencies? UGH. That's defini…
I'm talking out of my hat here a bit because I haven't actually worked with Android yet but it sounds to me that these problems might be related to the choice of Java as the core programming environment. I doubt that was a decision made by somebody working on a 20% project.
Re: The Care and Feeding of the Android GPU
#4Apparently touch responsiveness is improved in 2.3. However this article doesn't really explain what's wrong with it. I've been doing latency benchmarks for touch recently, and the highest latency I've seen for touch delivery is 10ms. Now 10ms is pretty terrible for what should be a very straightforward thing, but on the other hand it's only 2/3 of a frame, at 60 FPS.
The argument in favour of a GPU-accellerated GUI which is not mentioned here is battery life. I haven't been testing this side of things, but just because a CPU can do a 60 FPS GUI doesn't mean it should. Deferring it to the GPU would certainly reduce power consumption while navigating a UI. Whether this is non-negligible in terms of overall battery life, I'm not sure.
Re: The Care and Feeding of the Android GPU
#5Apparently touch responsiveness is improved in 2.3. However this article doesn't really explain what's wrong with it. I've been doing latency benchmarks for touch recently, and the highest latency I've seen for touch delivery is 10ms. Now 10ms is pretty terrible for what should be a very straightforward thing, but on the other hand it's only 2/3 of a frame, at 60 FPS. The argument in favour of a GPU-accellerated GUI…
Are those 10ms with a realistic app/usage scenario ? I wouldn't think users would complain about 10ms, isn't that below the threshold of perception ?
Re: The Care and Feeding of the Android GPU
#6Apparently touch responsiveness is improved in 2.3. However this article doesn't really explain what's wrong with it. I've been doing latency benchmarks for touch recently, and the highest latency I've seen for touch delivery is 10ms. Now 10ms is pretty terrible for what should be a very straightforward thing, but on the other hand it's only 2/3 of a frame, at 60 FPS. The argument in favour of a GPU-accellerated GUI…
You're seeing sub-10 mSec response times on projected capacitive screens? Care to share what you're analyzing? Cypress PSoC needs a good 20-30 to get a lock.
Re: The Care and Feeding of the Android GPU
#7I think the android bug linked in the article is much more informative than the article itself.
Basically: 1) Android phones can already animate the screen @ 60 fps in software in most cases. 2) When they can't, it's not because the CPU is too slow, it's because there is other stuff happening (GC, etc.). A GPU can't fix that.
Re: The Care and Feeding of the Android GPU
#8Apparently touch responsiveness is improved in 2.3. However this article doesn't really explain what's wrong with it. I've been doing latency benchmarks for touch recently, and the highest latency I've seen for touch delivery is 10ms. Now 10ms is pretty terrible for what should be a very straightforward thing, but on the other hand it's only 2/3 of a frame, at 60 FPS. The argument in favour of a GPU-accellerated GUI…
Actually, I wrote about battery life at the very end of the article. I already discussed battery life in a previous post. I certainly feel that battery life is one of the most important issues in mobile, hence, "efficiency"
As for touch responsiveness, I don't have enough current knowledge of Android's situation and touch hardware in general to write on that topic.
Re: The Care and Feeding of the Android GPU
#9I think the android bug linked in the article is much more informative than the article itself. Basically: 1) Android phones can already animate the screen @ 60 fps in software in most cases. 2) When they can't, it's not because the CPU is too slow, it's because there is other stuff happening (GC, etc.). A GPU can't fix that.
The GPU can offload most of the graphics intensive tasks from the CPU, utilizing the GPU instead of letting it sit idle. freeing the CPU to focus on GC tasks. In addition, most of the animation work done with Dalvik code can be moved into a dedicated thread / task with highly optimized code backing it.
Re: The Care and Feeding of the Android GPU
#10This isn't the first thing I've seen that Google devs really just didn't get. I think it's from the rapid expansion that Google has done. They get people working on things that aren't really their area of expertise because they wanted to try something in their 20% time. In this case, it's obvious that we've got server people working on mobile code. Future hardware will resolve these inefficiencies? UGH. That's defini…
I'm talking out of my hat here a bit because I haven't actually worked with Android yet but it sounds to me that these problems might be related to the choice of Java as the core programming environment. I doubt that was a decision made by somebody working on a 20% project.
Although Java has its problems, I think the core of Android's issue is a bad utilization of computing resources. One can only hope that Google will eventually fix this problem.
Palm's WebOS put much of its core logic in JavaScript, which had a slower implementation (at the time) than Dalvik VM does. However, Palm carefully made sure to take advantage of the GPU to achieve many of the effects in the UI.