2012-08-14 11 views
7

Tengo un problema con el tiempo de renderización muy bajo en una tableta Android usando los comandos NDK y egl. Tengo llamadas programadas al eglSwapBuffers y está tomando una cantidad de tiempo variable, con frecuencia excedió la velocidad de fotogramas del dispositivo. Sé que se sincroniza con la actualización, pero eso es alrededor de 60 FPS, y los tiempos aquí caen muy por debajo de eso.eglSwapBuffers es errático/lento

El único comando que emito entre las llamadas para intercambiar es glClear, así que sé que no es algo que estoy dibujando lo que causa el problema. Incluso con solo borrar la velocidad de cuadro, se reduce a 30 FPS (aunque errático).

En el mismo dispositivo, un programa GL simple en Java se procesa fácilmente a 60FPS, por lo que sé que no es fundamentalmente un problema de hardware. Revisé el código Android de Java para configurar el contexto GL y no puedo ver ninguna diferencia significativa. También he jugado con cada atributo de configuración, y aunque algunos alteran ligeramente la velocidad, ninguno (que pueda encontrar) cambia esta horrible caída de velocidad de cuadros.

Para garantizar que el sondeo del evento no fuera un problema, moví el renderizado a un hilo. Ese hilo ahora solo hace la representación, por lo tanto solo llama a borrar y cambiar varias veces. El rendimiento lento aún persiste.

No tengo ideas para comprobar y estoy buscando sugerencias sobre cuál podría ser el problema.

+0

intente comprobar si la medición en sí misma no consume tiempo, por si acaso. – Vasaka

+0

'eglSwapBuffers' es una llamada de bloqueo en Android y sí afecta a los fps a veces. También probaste 'android: hardwareAccelerated' – blganesh101

+0

¿Puedes publicar algún código? Incluyendo su código de evaluación comparativa si es posible. Por lo general, las llamadas que "comprometen" un estado OpenGL (un intercambio de buffer puede ser una de ellas) arruinan el benchmarking porque son las que realmente procesan todos los comandos anteriores que llamaste. Sin embargo, no estoy seguro de que sea posible, ya que solo está haciendo una clara diferencia entre los intercambios de memoria intermedia. De todos modos, veamos un poco de código. –

Respuesta

3

No hay suficiente información (como qué dispositivo está probando, cuál era su configuración exacta, etc.) para responder a esto 100% confiable, pero este tipo de comportamiento generalmente es causado por incompatibilidad de formato de píxeles de ventana y superficie, por ejemplo. 16 bits (RGB565) frente a 32 bits.

0

FB_MULTI_BUFFER=3 variable de entorno habilitará el almacenamiento en búfer múltiple en la placa Freescale i.MX 6 (Sabrelite) con alguna compilación LTIB reciente (sin X). Su controlador GFX puede necesitar algo como esto.

Cuestiones relacionadas