4 ms·

Linaro doubles performance for Android ICS

77 points by TobbenTM 14y ago

DiabloD3 14y ago
Notice that says "doubles over stock". OEMs are notorious for not properly configuring builds, so the real question is: how well does it perform against devices that already run some CM9-based build.
- mtgx 14y ago
  Well that point will be moot soon since CM9 will incorporate the optimization, but I wonder if Google will use it, too.
- Tanner 14y ago
  The reddit thread has some benchmarks: http://www.reddit.com/r/GalaxyNexus/comments/usos8/linaro_optimized_cm9_builds_for_vzw_and_gsm/c4yds2i http://www.reddit.com/r/GalaxyNexus/comments/usos8/linaro_op...
- buster 14y ago
  The article mentions notably faster on Galaxy Nexus.
trun 14y ago
What does this do to battery life?
- maratd 14y ago
  You're dealing with a higher quality build, so I would imagine you would have a bit more free space and bit more battery life.
mitchellh 14y ago
So what exactly did they do technically to double the performance of stock ICS? I read the article and watched a few minutes of the video and there was no detailed answer. The article itself didn't seem to link to any detailed resource either.
- edderly 14y ago
  It's not double the performance. It's a demo that if you use the software GLES implementation (which isn't used in production) they can run that benchmark at 60fps. The non-linaro toolchain GLES renders at less that 60 fps for this benchmark and then degrades to 30fps because the setup is double buffered and vsync'd.
  - barrkel 14y ago
    Vsync doesn't convert anything in the range of 31..59 FPS to 30 FPS. Vsync prevents fractional frame updates. You can still have any integer number of frames per second with vsync enabled. Anything less than 60FPS will just look like a dropped frame. (Double-buffering isn't particularly relevant to FPS that I can see. It just prevents you seeing the frame while it's being drawn, in practice it's mostly useful for reducing flicker from overdraw.)
    - edderly 14y ago
      It's related to double buffering and vsync together. If the pure rendering performance was 45fps, when the render is complete the next render can't progress until the buffer currently being displayed is available - hence degrades to 30 fps. http://www.anandtech.com/show/2794/2 http://www.anandtech.com/show/2794/2
      - barrkel 14y ago
        Ah OK. I was assuming a world in which triple-buffering was a given; in other words, that vsync in practice was a rendering implementation detail for avoiding tearing, rather than something that blocked the renderer. I can see how things are different on a resource-constrained device that can't afford triple-buffering. I'll add that usually you don't see a constant rate of rendering performance. Render time for a frame wanders above or below 16.67ms (with the design target being under that, if 60fps is the aim) depending on complexity or how busy other tasks are. It's not usually the case that every frame takes 22ms (i.e. 45fps) to produce; so it would be very unusual to see a game / app flip from 60fps straight to a locked 30fps. Rather, the odd frame will take slightly more than 16.666, with most falling under. The statistical distribution will give an FPS rate somewhere between 30 and 60.
edderly 14y ago
What's being demonstrated here isn't a real world usecase rather it is a demonstration that software (cpu based) GLES implementation can run at 60 fps with this test. In the production devices (and also available on Panda too) the actual GPU driver/libraries for the SGX540 is used. Practically this means that the Linaro tool chain won't double the performance of this test on a fuller environment. Additionally it's fairly specious to say 'double' the performance, on Android things are typically vsync'd and double buffered so if you render at < 60fps you will degrade to 30fps. IMO this is mildly disingenuous or at best naive and from a technical perspective Linaro should really do a better job trying to make their efforts relevant. They'd be better off showing off improvements in browser performance because the CPU is still used for some 2D rendering.
- krakensden 14y ago
  Does Android even use software GLES? I thought 3/4 of the point of modern smartphones was that they came with GPUs.
  - james_lan 14y ago
    Actually, in many cases Android does use the software renderer. Take a look at /system/lib/egl/egl.cfg In many cases where I've looked (though it varies on device) the software renderer does get picked up. If you remove the entry for the software renderer, it often speeds up in general, because hardware is forced to be used.
    - edderly 14y ago
      It practice it doesn't very often unless there's a very weird EGL configuration being requested which the h/w version doesn't support. But your point applies that you'd be better off removing the s/w renderer.
deleted 14y ago
[deleted]

77 points by TobbenTM 14y ago

Notice that says "doubles over stock". OEMs are notorious for not properly configuring builds, so the real question is: how well does it perform against devices that already run some CM9-based build.

mtgx 14y ago
Well that point will be moot soon since CM9 will incorporate the optimization, but I wonder if Google will use it, too.
Tanner 14y ago
The reddit thread has some benchmarks: http://www.reddit.com/r/GalaxyNexus/comments/usos8/linaro_optimized_cm9_builds_for_vzw_and_gsm/c4yds2i http://www.reddit.com/r/GalaxyNexus/comments/usos8/linaro_op...
buster 14y ago
The article mentions notably faster on Galaxy Nexus.

trun 14y ago

What does this do to battery life?

maratd 14y ago
You're dealing with a higher quality build, so I would imagine you would have a bit more free space and bit more battery life.

mitchellh 14y ago

So what exactly did they do technically to double the performance of stock ICS? I read the article and watched a few minutes of the video and there was no detailed answer. The article itself didn't seem to link to any detailed resource either.

edderly 14y ago
It's not double the performance. It's a demo that if you use the software GLES implementation (which isn't used in production) they can run that benchmark at 60fps. The non-linaro toolchain GLES renders at less that 60 fps for this benchmark and then degrades to 30fps because the setup is double buffered and vsync'd.
- barrkel 14y ago
  Vsync doesn't convert anything in the range of 31..59 FPS to 30 FPS. Vsync prevents fractional frame updates. You can still have any integer number of frames per second with vsync enabled. Anything less than 60FPS will just look like a dropped frame. (Double-buffering isn't particularly relevant to FPS that I can see. It just prevents you seeing the frame while it's being drawn, in practice it's mostly useful for reducing flicker from overdraw.)
  - edderly 14y ago
    It's related to double buffering and vsync together. If the pure rendering performance was 45fps, when the render is complete the next render can't progress until the buffer currently being displayed is available - hence degrades to 30 fps. http://www.anandtech.com/show/2794/2 http://www.anandtech.com/show/2794/2
    - barrkel 14y ago
      Ah OK. I was assuming a world in which triple-buffering was a given; in other words, that vsync in practice was a rendering implementation detail for avoiding tearing, rather than something that blocked the renderer. I can see how things are different on a resource-constrained device that can't afford triple-buffering. I'll add that usually you don't see a constant rate of rendering performance. Render time for a frame wanders above or below 16.67ms (with the design target being under that, if 60fps is the aim) depending on complexity or how busy other tasks are. It's not usually the case that every frame takes 22ms (i.e. 45fps) to produce; so it would be very unusual to see a game / app flip from 60fps straight to a locked 30fps. Rather, the odd frame will take slightly more than 16.666, with most falling under. The statistical distribution will give an FPS rate somewhere between 30 and 60.

edderly 14y ago

What's being demonstrated here isn't a real world usecase rather it is a demonstration that software (cpu based) GLES implementation can run at 60 fps with this test. In the production devices (and also available on Panda too) the actual GPU driver/libraries for the SGX540 is used. Practically this means that the Linaro tool chain won't double the performance of this test on a fuller environment. Additionally it's fairly specious to say 'double' the performance, on Android things are typically vsync'd and double buffered so if you render at < 60fps you will degrade to 30fps. IMO this is mildly disingenuous or at best naive and from a technical perspective Linaro should really do a better job trying to make their efforts relevant. They'd be better off showing off improvements in browser performance because the CPU is still used for some 2D rendering.

krakensden 14y ago
Does Android even use software GLES? I thought 3/4 of the point of modern smartphones was that they came with GPUs.
- james_lan 14y ago
  Actually, in many cases Android does use the software renderer. Take a look at /system/lib/egl/egl.cfg In many cases where I've looked (though it varies on device) the software renderer does get picked up. If you remove the entry for the software renderer, it often speeds up in general, because hardware is forced to be used.
  - edderly 14y ago
    It practice it doesn't very often unless there's a very weird EGL configuration being requested which the h/w version doesn't support. But your point applies that you'd be better off removing the s/w renderer.

deleted 14y ago

[deleted]