by Charles Ying

Posts Tagged ‘GPU’

The Care and Feeding of the Android GPU

Saturday, January 1st, 2011

Android has two major technical UX problems: animation performance and touch responsiveness.

Android’s UX architecture needs work. UI compositing and the view system are both primarily done in software. Garbage collection and async operations frequently block UI rendering.

Android team members are still in denial on the importance of GPU acceleration. They recommend eliminating garbage collection to improve animation performance. They say drawing isn’t the bottleneck and GPU accelerated 2D drawing won’t yield good results:

“It is very naive to think that using the GPU to render text and bitmaps is suddenly going to fix every issue you may see. There are many things that can be done to improve performance of the UI without using the GPU. Notably improving touch events dispatching, reducing garbage collection pauses, asynchronous operations to avoid blocking the UI thread, etc. A one year old NexusOne (and other devices before) is perfectly capable of scrolling a list at close to 60fps (limited by the display’s refresh rate.) Using GPUs to do 2D rendering can introduce other types of inefficiencies (fillrate can be an issue, some primitives like arbitrary shapes are complicated to render with antialiasing, textures need to be uploaded, shaders compiled, etc.) I am not saying we won’t do GPU rendering for the UI (I have worked on it myself a couple of times to test it) but please stop assuming that this is what has to be done right now.”
Romain Guy, Android software engineer

No one is saying that Android’s “2D primitive drawing” needs GPU acceleration. It’s Android’s view system and animation compositor that needs GPU acceleration. To compare, Core Graphics is still mostly software based while Core Animation is entirely GPU accelerated.

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. Smooth as butter, runs circles around the Nexus S Gingerbread browser on the same hardware!

Stop executing Dalvik Java VM code on every animation frame. Use the programmable GPU graphics pipeline. Add a scene graph if it makes sense. Run it on a separate thread. You might even get 32-bit graphics along the way.

Android engineers say that better hardware will eventually solve the problem — an insane rationale for the problem. On mobile, power efficiency is king. Throwing dual cores or more GHz at the problem is just going to get you more average performance with zero battery life, and even then, as long as your screen doesn’t get too big.

Wake up, Android team. Windows Phone 7 just lapped you.

Update: Additional discussion on Hacker News.

On Mobile Phone OS Design and GPUs

Wednesday, December 2nd, 2009

Mobile phones have really big screens.

Tablets will have even bigger screens.

If you want your mobile phone OS to matter in 2010, you’d better optimize for rendering graphics on the GPU.

GPUs are far more power efficient and faster at drawing graphics. As mobile device screens get really large, drawing the graphics “old school” on the CPU is moving from “unacceptable” to “impossible” pretty quickly.

Today, Motorola Droid runs at about half the frame rate of iPhone 3GS. The GPU in both is a PowerVR SGX 530 series chip.*

A PowerVR SGX 530 has a fill rate of 200 million pixels per second. That means Motorola Droid’s GPU could theoretically drive 8 full screen refreshes at 60 fps on a Droid-sized (WVGA) screen. All without the CPU’s help.

Parts of Android’s graphics subsystem seem to be GPU accelerated, but more is needed.

Imagine if the Android UX ran at a rock solid 60 fps. Then, I think we’d have something pretty sexy.

I wonder if Apple’s PA Semiconductor unit is designing GPUs instead of CPUs?

* It’s unclear what the exact model of the iPhone 3GS GPU is, and so the exact fill rate is not known… (though if it were, say, a PowerVR SGX 535, its fill rate would be 400 million pixels per second)

Technorati Tags: , , , , , , ,

Chocolux for WebGL = GPU raytracing in browser

Sunday, October 18th, 2009

I’ve just finished my port of Chocolux for WebGL (click for demo page).

Chocolux is a real-time recursive GPU raytracer using four spheres by Auld. Today, Chocolux now can run in your web browser.

The implications of this are pretty mind blowing. WebGL now allows compiled code to run on the GPU. Imagine what games, image processing, and applications will be possible with compiled shaders and general GPU computing (OpenCL?) now in the browser. And with WebGL gaining widespread adoption, it’s going to be here fairly soon.*

For more information about cutting edge fragment shader GPU raytracing and rendering, check out Rendering Worlds with Two Triangles (PDF).

*pending completion of a stable WebGL spec, naturally.

Technorati Tags: , , , , ,