Optimización de juegos de Unity* en Android* para la arquitectura Intel®: estudio de un caso

Descargar el documento

Unity* es uno de los motores de juegos más difundidos del entorno móvil (Android* e iOS*), y muchos desarrolladores lo utilizan para desarrollar juegos. Antes de que Unity admitiera Android en plataformas Intel, los juegos se ejecutaban en un emulador que cambiaba el código nativo ARM* a código nativo Intel. Algunos juegos x86 no nativos para plataformas Intel no funcionaban y otros tenían problemas de rendimiento. Con el aumento de la cuota de mercado de los procesadores Intel en el sector móvil, muchos desarrolladores están interesados en ofrecer compatibilidad con Android en la arquitectura x86 y desean saber cómo optimizar sus juegos.

En este artículo mostraremos cómo incrementar el rendimiento con compatibilidad nativa con Android y daremos sugerencias para aumentar el rendimiento en la arquitectura Intel®. Usaremos como ejemplo Hero Sky: Epic Guild Wars.

Figura 1. Hero Sky: Epic Guild Wars

Innospark, la empresa creadora de Hero Sky: Epic Guild Wars, tiene abundante experiencia en el desarrollo de juegos para dispositivos móviles con varios motores de juegos de uso comercial y también tiene el suyo propio. Hero Sky: Epic Guild Wars es el primer juego basado en Unity que lanzan al mercado mundial. Cuando comenzaron a aumentar la cantidad de descargas desde la tienda Google Play*, la empresa comenzó a recibir quejas de que el juego no funcionaba y que tenía retardos en algunos dispositivos con procesador Intel y sistema operativo Android. Innospark decidió portar y optimizar el juego para Android en la arquitectura Intel. En este artículo contamos qué hizo Innospark para optimizar a partir de los resultados de análisis de perfiles de Intel® Graphics Performance Analyzers (Intel® GPA), como el cambio en el orden de dibujo y la eliminación de mezclas alfa innecesarias.

Introducción

Hero Sky: Epic Guild Wars es un juego de estrategia de combate en línea con gráficos full 3D. Innospark lo desarrolló y optimizó en una plataforma basada en un procesador Intel® Atom™ (nombre clave Bay Trail). A continuación se incluye el diseño de referencia de Bay Trail y sus especificaciones.

CPU	Procesador Intel® Atom™ Quad Core 1.46 Ghz
Sistema operativo	Android* 4.4.4
RAM	2GB
Resolución	1920x1200
Puntaje de 3DMark* ICE Storm Unlimited	10,386
Puntaje de gráficos	9,274
Puntaje de física	17,899

Tabla 1. Especificación del diseño de referencia “Bay Trail 8” y puntaje de 3DMark*

El gráfico que sigue muestra una comparación de rendimiento entre código x86 no nativo y código nativo en el diseño de referencia Bay Trail.

Figura 2. Aumento de rendimiento al incorporar compatibilidad nativa con x86.

El software y las cargas de trabajo que se usan en la pruebas de rendimiento puede que hayan sido optimizadas para rendimiento solamente en microprocesadores Intel. Las pruebas de rendimiento, tales como SYSmark* y MobileMark*, se miden con sistemas informáticos, componentes, software, operaciones y funciones específicos. Todo cambio en cualquiera de esos factores puede hacer que varíen los resultados. Debe consultar más información y otras pruebas de rendimiento que lo ayuden a evaluar íntegramente las compras que contemple hacer, incluido el rendimiento del producto al combinarlo con otros. Si desea conocer más información, visite http://www.intel.com/performance.

Después de portar el juego para Android en la arquitectura Intel, la carga de CPU se redujo en aproximadamente 7,1 %, la frecuencia de fotogramas (fps) aumentó un 27,8 % y el tiempo de ejecución disminuyó un 32,6 %. Sin embargo, el uso de la GPU se incrementó un 26,7 % debido al aumento de la frecuencia de fotogramas.

Innospark utilizó Intel GPA para buscar cuellos de botella de la CPU y la GPU durante el desarrollo y se sirvió de los análisis para resolver problemas gráficos y de rendimiento.

Intel GPA System Analyzer midió 59,01 fps como rendimiento de referencia. Graphics Frame Analyzer, que mide los fps solo del lado de la GPU, detectó 120,9 fps. Esta diferencia de valores se explica porque System Analyzer monitorea la actividad en directo del proceso, que incluye tanto el trabajo de la CPU como el de la GPU, y Graphics Frame Analyzer incluye el trabajo relacionado con la GPU más las actividades de la CPU que tienen relación directa con el envío de datos al controlador y la GPU.

Análisis en profundidad con Graphics Frame Analyzer

Figura 3 Captura de pantalla de la versión de referencia

Después de la portación, la frecuencia de fotogramas fue de 59,01 fps. Lo analizamos en mayor detalle con Graphics Frame Analyzer para reducir el uso de la GPU y la carga de la CPU. En las tablas siguientes se muestra la información obtenida con Graphics Frame Analyzer.

Cantidad total de primitivas	4,376
Duración en GPU (ms)	8.56 ms
Tiempo para mostrar el fotograma (ms)	9.35 ms

Tabla 2. Información de fotograma de referencia

Tipo	Erg	Duración en GPU (ms)	Lectura de memoria de GPU(MB)	Escritura de memoria de GPU(MB)
Cielo	1	1.43 ms	0.2 MB	7.6 MB
Terreno	5	1.89 ms	9.4 MB	8.2 MB

Tabla 3. El elevado costo de las llamadas a dibujo de la versión de referencia.

Análisis y optimización de la cantidad de llamadas a dibujo

Eliminación de las mezclas alfa innecesarias

Cuando un objeto que se visualiza en pantalla usa mezcla alfa, el runtime debe combinar los valores de color de cada objeto apilado de ese tipo y el color de fondo para determinar el color definitivo. Por lo tanto, la mezcla alfa exige más al procesador que el dibujar colores opacos. Estos cálculos adicionales pueden afectar el rendimiento en dispositivos lentos. Conviene entonces eliminar las mezclas alfas innecesarias.

Graphics Frame Analyzer tiene la capacidad de habilitar o deshabilitar cada llamada a dibujo, de modo que el desarrollador realice pruebas y mediciones sin modificar la fuente. Esta función se encuentra en la pestaña de estado de mezcla “Blend State“, debajo de la pestaña “State”.

Figura 4. Cómo hacer pruebas con la habilitación y deshabilitación de la mezcla alfa en Graphics Frame Analyzer sin modificar la fuente

En la tabla de abajo se muestra información más detallada acerca de las llamadas a dibujo del césped después de deshabilitar la mezcla alfa. La duración del césped en la GPU se redujo en un 26,0 %. También se observa que la lectura de memoria de la GPU disminuyó un 97,2 %.

	Referencia	Orden de dibujo cambiado (cielo)
Relojes de GPU	1,466,843	1,085,794.5
Duración en GPU (µs)	1,896.6 us	1,398.4 us
Lectura de memoria de GPU (MB)	7.6 MB	0.2 MB
Escritura de memoria de GPU (MB)	8.2 MB	8.2 MB

Tabla 4. Información detallada de las llamadas a dibujo después de deshabilitar la mezcla alfa

Aplicación eficaz de culling en Z

Cuando la tarjeta gráfica 3D representa un objeto, los datos 3D se convierten a 2D (x, y) y se utiliza el búfer Z, o búfer de profundidad, para almacenar la información de profundidad (coordenada z) de cada píxel de pantalla. Si dos objetos de la escena se deben representar en el mismo píxel, la GPU compara ambas profundidades y reemplaza el píxel actual si el nuevo objeto está más cerca del observador. La técnica de culling de Z reproduce la percepción de profundidad habitual, y para ello dibuja primero los objetos más cercanos, de manera que oculten a los más alejados. Esta técnica mejora el rendimiento cuando se representan superficies ocultas.

El juego que estamos analizando tiene dos tipos de dibujo de grandes superficies: cielo y césped. La llamada a dibujo erg 1 es para el cielo, y erg 5 es la llamada a dibujo para el césped. Como hay grandes cantidades de cielo detrás del césped, hay muchas partes de cielo que nunca se muestran durante el juego. Sin embargo, el cielo se representaba antes que el césped, lo cual afectaba la eficiencia del culling en Z.

Figura 5. Llamada a dibujo para el cielo (erg 1) y el césped (erg 5)

Debajo se muestra la duración del cielo en la GPU después de cambiar el orden de dibujo.

Figura 6. Resultado después de cambiar el orden de dibujo del cielo en Graphics Frame Analyzer.

En la tabla de abajo se muestra información más detallada acerca del cielo después de cambiar el orden de dibujo. La duración del césped en la GPU se redujo en un 88,0%. Se observa que la escritura de memoria de la GPU disminuyó un 98,9%.

	Referencia	Orden de dibujo cambiado (cielo)
Relojes de GPU	1,113,276	133,975
Duración en GPU (µs)	1,433 us	174.2 us
Fragmentos con errores de profundidad	0	2,145,344
Muestra escrita	2,165,760	20,416
Lectura de memoria de GPU (MB)	0.2 MB	0.0 MB
Escritura de memoria de GPU (MB)	9.4 MB	0.1 MB

Tabla 5. Información detallada de las llamadas a dibujo después de cambiar el orden de dibujo (cielo).

Resultados

En la tabla siguiente se muestra información más detallada de optimización para x86 después de eliminar las mezclas alfa innecesarias y modificar el orden de dibujo. La duración en la GPU se redujo en aproximadamente 25 %, y la lectura y la escritura de memoria de la GPU se redujeron en un 42,6 % y un 30,0 %, respectivamente. System Analyzer mostró que la frecuencia de fotogramas solo aumentó 1,06, porque Android usa el modo vsync y el máximo valor es 60 fps, pero la frecuencia en Graphics Frame Analyzer se incrementó en un 29,7 %.

	X86 de referencia	X86 con optimización
Relojes de GPU	6,654,210	4,965,478
Duración en GPU (µs)	8,565.2 us	6,386 us
Fragmentos con errores de profundidad	16,592	2,248,450
Muestra escrita	6,053,311	2,813,997
Lectura de memoria de GPU (MB)	20.9 MB	12.0 MB
Escritura de memoria de GPU (MB)	28.6 MB	20.0 MB
Fps en System Analyzer	59.01	60.07
Fps en Graphics Frame Analyzer	120.9	156.8

Tabla 6. Aumentos de rendimiento después de deshabilitar las mezclas alfa y de cambiar el orden de dibujo (cielo).

Figura 7. Aumento de rendimiento al optimizar la compatibilidad nativa con x86.

Conclusión

Lo primero que deben hacer los desarrolladores al optimizar juegos en Android x86 es portar sus juegos para Android x86 y a continuación determinar el cuello de botella de la aplicación. Las herramientas de análisis de perfiles ayudan a medir el rendimiento y detectar con mayor facilidad dónde hay problemas de rendimiento del lado de la GPU. Las potentes herramientas de análisis de Intel GPA ofrecen la posibilidad de experimentar sin modificar la fuente.

Acerca de los autores

Jackie Lee es ingeniero de aplicaciones del Grupo de Software y Soluciones de Intel. Su trabajo se centra en el ajuste de rendimiento de aplicaciones en plataformas Intel Atom. Con anterioridad, trabajó en el departamento de tecnología electrónica de LG. Tiene una maestría y una licenciatura en Ingeniería y Ciencias de la Computación de la Universidad ChungAng.