2

We have an embedded system that uses TI 8168 based h/w. This SOC has SGX 530 as its GPU. We are running Android 4.0.3 on this platform. We found the frame rate of Android apps seem to be low compared to same app running on similarly powered tablet.

After timing various functions in Android activity, android platform code, we noticed eglSwapBuffer() is taking 45+ ms most of the times. What I read in various forums is that it should not be more than 16ms. The resolution of the frame buffer is 1920x1080.

I appreciate any suggestions to fix this bottleneck.

The driver version (i.e /proc/pvr/version contents)

Version blaze_android_sgx_ogles1_ogles2_GPL sgxddk 18 1.8@789263 (release) omap4430_android
System Version String: SGX revision = 1.2.5

The contents of egl.cfg from /system/lib/egl folder:

0 0 android
0 1 POWERVR_SGX530_125

The contents of /system/lib/egl folder

egl.cfg
libEGL_POWERVR_SGX530_125.so
libGLES_android.so
libGLESv1_CM_POWERVR_SGX530_125.so
libGLESv2_POWERVR_SGX530_125.so

The contents of rc.pvr script from /system/bin/sgx folder

#!/system/bin/sh

# PowerVR SGX DDK for Embedded Linux - installation script
#
# Copyright 2004-2006 by Imagination Technologies Limited.
# All rights reserved. No part of this software, either
# material or conceptual may be copied or distributed,
# transmitted, transcribed, stored in a retrieval system
# or translated into any human or computer language in any
# form by any means, electronic, mechanical, manual or
# other-wise, or disclosed to third parties without the
# express written permission of Imagination Technologies
# Limited, Unit 8, HomePark Industrial Estate,
# King's Langley, Hertfordshire, WD4 8LZ, U.K.

# Auto-generated for omap4430_android from
# $RCSfile: common.m4 $ $Revision: 1.8 $
# $RCSfile: rc.pvr.m4 $ $Revision: 1.26 $
# $RCSfile: rc.pvr.m4 $ $Revision: 1.5 $
#

load_pvr()
{
/system/bin/devmem2 0x48180F04 w 0x0
/system/bin/devmem2 0x48180900 w 0x2
/system/bin/devmem2 0x48180920 w 0x2

insmod /system/bin/sgx/pvrsrvkm.ko
insmod /system/bin/sgx/omaplfb.ko
sleep 1
chmod 0666 /dev/pvrsrvkm
/system/bin/pvrsrvinit
echo "Loaded PowerVR consumer services."
return 0;
}

unload_pvr()
{
if rmmod omaplfb; then :; else return 1; fi
if rmmod pvrsrvkm; then :; else return 1; fi
echo "Unloaded PowerVR consumer services."
return 0;
}

# Deal with the type of invocation we get.
#
case "$1" in
"start")
load_pvr
;;
stop)
if ! unload_pvr; then
echo "Couldn't unload modules" >&2;
fi
;;
reload|restart)
if unload_pvr; then
load_pvr
else
echo "Couldn't unload modules" >&2;
fi
;;
*)
echo "$0: unknown argument $1." >&2;
;;
esac

The surfaceflinger logs when it is coming up:

SurfaceFlinger(687): starting up service SurfaceFlinger
SurfaceFlinger(687): SurfaceFlinger is starting
SurfaceFlinger(687): Initializing thread for: SurfaceFlinger
SurfaceFlinger(687): SurfaceFlinger's main thread ready to run. Initializing graphics H/W...
SurfaceFlinger(687): ro.sf.lcd_density not defined, using 160 dpi by default.
SurfaceFlinger(687): EGL informations:
SurfaceFlinger(687): # of configs : 30
SurfaceFlinger(687): vendor    : Android
SurfaceFlinger(687): version   : 1.4 Android META-EGL
SurfaceFlinger(687): extensions: EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_fence_sync EGL_ANDROID_image_native_buffer EGL_ANDROID_image_native_buffer 
SurfaceFlinger(687): Client API: OpenGL ES
SurfaceFlinger(687): EGLSurface: 8-8-8-8, config=0x1
SurfaceFlinger(687): OpenGL informations:
SurfaceFlinger(687): vendor    : Imagination Technologies
SurfaceFlinger(687): renderer  : PowerVR SGX 530
SurfaceFlinger(687): version   : OpenGL ES-CM 1.1
SurfaceFlinger(687): extensions: GL_OES_byte_coordinates GL_OES_fixed_point GL_OES_single_precision GL_OES_matrix_get GL_OES_read_format GL_OES_compressed_paletted_texture GL_OES_point_sprite GL_OES_point_size_array GL_OES_matrix_palette GL_OES_draw_texture GL_OES_query_matrix GL_OES_texture_env_crossbar GL_OES_texture_mirrored_repeat GL_OES_texture_cube_map GL_OES_blend_subtract GL_OES_blend_func_separate GL_OES_blend_equation_separate GL_OES_stencil_wrap GL_OES_extended_matrix_palette GL_OES_framebuffer_object GL_OES_rgb8_rgba8 GL_OES_depth24 GL_OES_stencil8 GL_OES_compressed_ETC1_RGB8_texture GL_OES_mapbuffer GL_OES_EGL_image GL_OES_EGL_image_external GL_EXT_multi_draw_arrays GL_OES_required_internalformat GL_IMG_read_format GL_IMG_texture_compression_pvrtc GL_IMG_texture_format_BGRA8888 GL_EXT_texture_format_BGRA8888 GL_OES_egl_sync GL_IMG_vertex_array_object
SurfaceFlinger(687): GL_MAX_TEXTURE_SIZE = 2048
SurfaceFlinger(687): GL_MAX_VIEWPORT_DIMS = 2048 x 2048
SurfaceFlinger(687): flags = 00010000
SurfaceFlinger(687): This platform does not support HW composer
videoguy
  • 1,732
  • 2
  • 24
  • 49
  • `eglSwapBuffers()` sends the "back" buffer to the "front"; on Android, this means sending the buffer you're rendering to the SurfaceFlinger compositor. Each `Surface` has a pool of buffers (probably 3). Ideally, if you're rendering faster than the display, you'll get a new buffer when the display releases the old one; on a 60fps device that will happen every 16.7 ms. If the panel is slower than 60fps, you will see a longer time between frames. Do you have any apps that run faster than 22fps on this device? – fadden Feb 26 '14 at 01:11
  • I timed eglSwapBuffers as it is invoked by SurfaceFlinger after compositing etc are done. The app that is pushing the updates is probably doing it less than 30fps rate. The eglSwap... time didn't get lower even when the app was pushing updates at 2fps. – videoguy Feb 26 '14 at 02:46

1 Answers1

3

Ensure that the SGX is clocked at 333 MHz (refer to http://processors.wiki.ti.com/index.php/AM35x-OMAP35x_Graphics_SDK_Getting_Started_Guide). Beyond that, there is little you can do to push the limits of sgx530 on this platform. 16 mSec translates to 60 fps, and the SGX530 can drive 1080P resolution at this rate, only for blits, without any additional processing. This is not the case in Android, where SGX is used practically for everything.

Note that in this platform, the entire draw actually happens in swapbuffers due to the architecture.

Prabindh
  • 3,356
  • 2
  • 23
  • 25
  • If I see these numbers when the app is drawing a lot, I can understand. I see 45+ms even when the app drew a line in 5x5 area. Is there a way to measure sgx load during these times? – videoguy Feb 26 '14 at 02:59
  • Its not just your app that is using SGX. Android uses SGX for drawing and compositing all windows on the screen, in addition to what your application does. You can use pvrtune to check the load. Check the same Wiki link above for details – Prabindh Feb 26 '14 at 03:05
  • 1
    The SGX 530 is a stripped-down low-performance version of the PowerVR architecture. Don't expect it to ever perform as well as GPUs in Intel Atom, Freescale, Nvidia or Qualcomm devices. – ClayMontgomery Feb 26 '14 at 16:54
  • I got PVRTrace for my app working and loaded generated .pvrt file in PVRTrace GUI app. I am surprised to find lot of GL calls (200+) for every frame. When I changed focus from one button to next, I was expecting fewer gl calls with dirty rect set to bounding rectangle of two buttons. It looked like it is drawing the whole thing from scratch. SGX is clocked at 333MHz. – videoguy Feb 26 '14 at 23:25