iPhone optimización de rendimiento de openGLES

Question

Estoy intentando por un buen tiempo optimizar la velocidad de fotogramas de mi juego sin realmente avanzar. Estoy ejecutando el último iPhone SDK y tengo un dispositivo iPhone 3G 3.1.2.

Invoco alrededor de 150 drawcalls, que representan aproximadamente 1900 Triangles en total (todos los objetos se texturizan usando dos capas de textura y multitextura. La mayoría de las texturas provienen de la misma texturaAtlasTexture almacenada en pvrtc 2bpp comprimido textura). Esto se renderiza en mi teléfono a alrededor de 30 fps, lo que me parece demasiado bajo para solo 1900 triángulos.

Intenté muchas cosas para optimizar el rendimiento, incluyendo agrupar los objetos en lotes, transformar los vértices en la CPU y representarlos en una sola invocación. este yelds 8 drawcalls (como opuesto a 150 drawcalls), pero el rendimiento es más o menos el mismo (fps caen alrededor de 26fps)

Estoy usando vértices de 32byte almacenados en una matriz intercalada (12bytes position, 12bytes normales, 8bytes uv) . Estoy renderizando TriangleLists y los vértices están ordenados en orden TriStrip.

Hice algunos perfiles, pero realmente no sé cómo interpretarlo.

1. instrumentos relacionados con el muestreo utilizando instrumentos y Toma de Muestras yelds este resultado: http://neo.cycovery.com/instruments_sampling.gif me dice que una gran cantidad de tiempo que se gasta en "mach_msg_trap". Busqué en Google y parece que se llama a esta función para esperar otras cosas. Pero espera ¿qué?

2. instrumentos en OpenGL instrumentos con los yelds módulo OpenGL este resultado: http://neo.cycovery.com/intstruments_openglES_debug.gif pero aquí he realmente ni idea de lo que me están diciendo esos números

3. perfiles de tiburón: perfiladora de tiburón no le dijo me mucho tampoco: http://neo.cycovery.com/shark_profile_release.gif el número más grande es de 10%, pasó por drawTriangles - y todo el resto se gasta en funciones de porcentaje muy pequeñas

¿Alguien puede decirme qué más podría hacer para descubrir el cuello de botella y podría ayudarme a interpretar esa información de perfil?

¡Muchas gracias!

Answer 1

estoy por desgracia no muy versado en OpenGL, pero aquí hay algunas cosas a destacar en mí desde los tres resultados:

1) del instrumento de muestreo, es posible que tenga algún tipo de conexión de la tela de fondo va?

2) Los porcentajes de utilización representados me parecen bajos (aunque no sé cómo mejorarlos).

3) Aunque el 10% parece bajo, parece un buen punto de ataque; sin embargo, es casi igualmente sospechoso que haya tanto tiempo dedicado a memcpy. Además, ValidateState es una cantidad bastante grande y podría estar frenando.

Herramientas Creo que está utilizando las herramientas adecuadas para examinar el rendimiento, solo necesita pensar más sobre lo que significa para su aplicación.

Answer 2

Probablemente estés vinculado a la CPU. Las estadísticas de utilización del revendedor/procesador en el instrumento OpenGL ES muestran que el ciclo de trabajo de la GPU está entre 20-30% para rendir a 20-30 fps, lo que sugiere que la GPU podría funcionar a 60 fps si se alimenta lo suficientemente rápido. Parece que hay algunas cosas que podría hacer para obtener más información de Instruments y Shark sobre qué buscar:

De forma predeterminada, Sampler muestra cada muestra de cada hilo, lo que significa que se crearon hilos de ayuda en su mayoría inactivos por los marcos del sistema dominarán su punto de vista. Para tener una mejor idea de lo que realmente hace la CPU, asegúrese de que se muestre la Vista de detalles (tercer botón desde la izquierda en la esquina inferior izquierda) y cambie Perspectiva de muestra a Tiempos de muestra en ejecución para excluir muestras donde una secuencia está inactiva/bloqueada .

No veo ninguna muestra en el rastro de Shark desde su propia aplicación. Puede ser porque su código es lo suficientemente rápido como para que no aparezca en ninguna parte de la lista de funciones activas, pero también podría deberse a que Shark no puede encontrar símbolos para su aplicación. Puede que necesite configurar las rutas de búsqueda en sus preferencias o señalar manualmente Shark en el binario de su aplicación. Además, Shark muestra de manera predeterminada una lista de funciones ordenadas por la cantidad de tiempo de CPU que se gasta en ellas. Puede ser útil cambiar la vista a algo más parecido a un árbol de llamadas regulares, de modo que pueda visualizar cómo su ciclo de renderizado general pasa su tiempo. Para ello, cambie la opción Ver en la esquina inferior derecha a "Árbol (Arriba-Abajo)." (Si no ve el nombre o las funciones de su aplicación aquí, entonces Shark definitivamente no tiene sus símbolos.)

Answer 3

Sin la fuente completa, es difícil decir exactamente lo que está sucediendo. El rastro de Instrumentos muestra un 20% de utilización del renderizado, que es un poco bajo. Esto probablemente significa que estás atado a la CPU. Sin embargo, si este fuera el caso, esperaría ver más puntos de muestra específicos de la aplicación en su primer rastreo.

Mi consejo es rodar su propia clase de tiempo. Algo como esto (C++):

#include <sys/time.h> 

class Timer 
{ 
public: 
    Timer() 
    { 
     gettimeofday(&m_time, NULL); 
    } 
    void Reset() 
    { 
     gettimeofday(&m_time, NULL); 
    } 
    // returns time since construction or Reset in microseconds. 
    unsigned long GetTime() const 
    { 
     timeval now; 
     gettimeofday(&now, NULL); 
     unsigned long micros = (now.tv_sec-m_time.tv_sec)*1000000+ 
           (now.tv_usec-m_time.tv_usec); 
     return micros; 
    } 
    protected: 
     timeval m_time; 
}; 

Mida sus secciones de código para saber exactamente dónde se está gastando su tiempo.

Otra solución rápida es desactivar el conjunto de instrucciones de Thumb. Esto podría ayudar a su rendimiento de punto flotante 20% o más, a expensas del tamaño de su ejecutable.

Answer 4

Si está utilizando glFlush o glFinish, elimine todos esos.