Evaluación comparativa de rendimiento en Unity: Cómo empezar
Como desarrollador de Unity , quieres que a tus usuarios les encante jugar tus juegos y que disfruten de una experiencia fluida en todas las plataformas en las que puedan jugar. ¿Qué pasaría si te dijera que acabamos de hacer más fácil la creación de puntos de referencia de rendimiento? Si quieres aprender a desarrollar juegos o herramientas Unity teniendo en cuenta el rendimiento, ¡sigue leyendo!
En esta publicación, explico cómo usar un par de herramientas de Unity que le brindan una manera fácil de comenzar a recopilar métricas de rendimiento y crear puntos de referencia con ellas: Unity Test Runner que viene con Unity Editor, Unity Performance Testing Extensiony Unity Performance Benchmark Reporter.
Como desarrollador de Unity , es posible que se encuentre en la siguiente situación: su proyecto se ejecutaba de manera rápida y fluida no hace mucho tiempo, pero luego se produjeron uno o más cambios y ahora las escenas son notablemente lentas, los cuadros se caen y han comenzado a aparecer otros problemas de rendimiento. Puede resultar difícil rastrear qué cambios provocaron la regresión del rendimiento.
Si es socio de Unity , desea comprender los cambios de rendimiento en sus SDK, controladores, plataformas, paquetes u otros artefactos. O desea recopilar métricas de rendimiento en diferentes versiones de Unity con sus productos, pero no está muy claro cómo hacerlo y luego hacer las comparaciones.
Estos son sólo un par de ejemplos en los que establecer puntos de referencia de rendimiento realmente puede salvar el día. Ahora, permítame mostrarle cómo puede comenzar a recopilar métricas de rendimiento, crear puntos de referencia con ellas y visualizar cambios en las métricas de rendimiento.
Para esta discusión, analizaremos el código de prueba en el proyecto de prueba de rendimiento de muestra UnityPerformanceBenchmark.
Descargue la última versión de XRAutomatedTests desde GitHub. Encontrará el proyecto UnityPerformanceBenchmark en el subdirectorio PerformanceTests.
El proyecto UnityPerformanceBenchmark contiene una variedad de escenas de muestra que a su vez se utilizan en pruebas de rendimiento de Unity mediante la extensión de pruebas de rendimiento de Unity .
Lo primero que vamos a hacer es ver cómo escribimos pruebas de rendimiento utilizando Unity Test Runner con la extensión Unity Performance Testing. A continuación encontrará un poco de información general sobre ambas herramientas antes de continuar.
Estamos utilizando Unity Test Runner para ejecutar nuestras pruebas de rendimiento. Unity Test Runner es un marco de ejecución de pruebas integrado en Unity Editor que le permite probar su código tanto en modo de edición como de reproducción en reproductores de plataformas de destino como Standalone, Android o iOS. Si no está familiarizado con Unity Test Runner, consulte la documentación de Unity Test Runner.
La extensión de pruebas de rendimiento de Unity es un paquete del editor de Unity que proporciona una API y atributos de casos de prueba que le permiten muestrear y agregar marcadores de perfiladores de Unity y métricas personalizadas que no son de perfiladores, en el editor de Unity y los reproductores. Puede obtener más información consultando la documentación de la extensión de pruebas de rendimiento de Unity, pero veremos algunos ejemplos aquí.
La extensión de prueba de rendimiento de Unity requiere Unity 2018.1 o superior. Asegúrese de utilizar la versión 2018.1 de Unity o superior si desea ejecutar las pruebas de rendimiento de muestra en el proyecto UnityPerformanceBenchmark o siempre que utilice la extensión de prueba de rendimiento de Unity .
El proyecto UnityPerformanceBenchmark implementa la interfaz IPrebuildSetup , una función de Unity Test Runner, donde podemos implementar un método Setup que se llama automáticamente antes de que Unity Test Runner ejecute la prueba.
Lo primero que hace el método IPrebuildSetup.Setup del proyecto UnityPerformanceBenchmark es analizar los argumentos de la línea de comandos en busca de configuraciones de compilación del reproductor. Esto nos permite construir de manera flexible el reproductor para nuestras pruebas de rendimiento usando el mismo proyecto de Unity contra diferentes plataformas, modos de subprocesamiento de renderizado, API de gráficos del reproductor, implementaciones de scripts y configuraciones habilitadas para XR, como ruta de renderizado estéreo y SDK de VR .
Por lo tanto, necesitaremos abrir el proyecto UnityPerformanceBenchmark con Unity desde la línea de comandos, pasando las opciones de compilación del reproductor que queremos usar cuando ejecutemos las pruebas en Unity Test Runner.
Ejemplo: Inicie el proyecto UnityPerformanceBenchmark desde Windows para crear Android Player:
Unity.exe -projectPath
C:\XRAutomatedTests-2018.2\PerformanceTests\UnityPerformanceBenchmark
-Plataforma de prueba Android -buildTarget Android -playergraphicsapi=OpenGLES3 -mtRendering -scriptingbackend=mono
Aquí lanzamos Unity en Windows para compilar para Android con API de gráficos OpenGLES3, renderizado multiproceso y backend de scripting mono.
Ejemplo: Ejecute el proyecto UnityPerformanceBenchmark desde OSX para crear un reproductor iOS
./Unity -projectPath /XRAutomatedTests-2018.2/PerformanceTests/UnityPerformanceBenchmark
-Plataforma de prueba iOS -buildTarget iOS -playergraphicsapi=OpenGLES3 -mtRendering -scriptingbackend=mono
-appleDeveloperTeamID=<yourAppleDeveloperTeamID>
-iOSProvisioningProfileID=<yourIosProvisionProfileID>
Aquí lanzamos Unity en OSX para compilar para iOS con API de gráficos OpenGLES3, renderizado multiproceso y backend de scripting mono. También proporcionamos al equipo de desarrolladores de Apple y la información del perfil de aprovisionamiento necesaria para la implementación en un dispositivo iOS.
Cuando abrimos el proyecto UnityPerformanceBenchmark con Unity desde la línea de comando como en los ejemplos anteriores, los argumentos de la línea de comando estarán en la memoria para que el método IPrebuildSetup.Setup los analice y los use para construir el reproductor.
Si bien este enfoque de lanzamiento desde la línea de comandos no es necesario para ejecutar pruebas en Unity Test Runner, es un buen patrón para usar para evitar usar un proyecto de prueba separado para cada configuración de reproductor.
He detallado las opciones de la línea de comandos para abrir el proyecto, o simplemente ejecutar las pruebas, desde la línea de comandos en la wiki del proyecto de prueba: Cómo ejecutar las pruebas comparativas de rendimiento de Unity. Para obtener más información sobre cómo analizamos la configuración de compilación del reproductor en el proyecto de prueba, consulte el archivo RenderPerformancePrebuildStep.cs en el directorio Scripts del proyecto de prueba UnityPerformanceBenchmark.
Después de abrir UnityPerformanceBenchmark, necesitamos abrir la ventana Unity Test Runner en el Editor de Unity
- en Unity 2018.1, vaya a Ventana > Ejecutor de pruebas.
- en Unity 2018.2, vaya a Ventana > General > Ejecutor de pruebas.
Se abrirá la ventana Unity Test Runner y se verá como la imagen de abajo.
Estas son nuestras pruebas de rendimiento de Unity . Podemos ejecutarlos en el Editor usando el botón Ejecutar en la parte superior izquierda de la ventana, o en el dispositivo o plataforma real usando el botón “Ejecutar todo en el reproductor” en la parte superior derecha de la ventana.
Consejo de depuración
Si desea depurar código en su método IPrebuildSetup.Setup
1. Establezca puntos de interrupción en su código IPrebuildSetup.Setup en Visual Studio
2. Adjuntar al Editor de Unity con la extensión Visual Studio Tool for Unity
3. Ejecute sus pruebas en el Editor usando el botón “Ejecutar todo” o “Ejecutar seleccionar” en la ventana Unity Test Runner.
En este punto, el depurador de Visual Studio ingresará a su código donde podrá depurarlo según sea necesario.
Echemos un vistazo a un ejemplo de prueba de rendimiento para que podamos comprender mejor cómo funciona.
Ejemplo: Muestreo de marcadores de perfiladores en una prueba de rendimiento de Unity
[PerformanceUnityTest]
public IEnumerator SpiralFlame_RenderPerformance()
{
yield return SceneManager
.LoadSceneAsync(spiralSceneName, LoadSceneMode.Additive);
SetActiveScene(spiralSceneName);
// Instantiate performance test object in scene
var renderPerformanceTest =
SetupPerfTest<DynamicRenderPerformanceMonoBehaviourTest>();
// allow time to settle before taking measurements
yield return new WaitForSecondsRealtime(SettleTime);
// use ProfilerMarkers API from Performance Test Extension
using (Measure.ProfilerMarkers(SamplerNames))
{
// Set CaptureMetrics flag to TRUE;
// let's start capturing metrics
renderPerformanceTest.component.CaptureMetrics = true;
// Run the MonoBehaviour Test
yield return renderPerformanceTest;
}
yield return SceneManager.UnloadSceneAsync(spiralSceneName);
}En este ejemplo, nuestro método de prueba se llama SpiralFlame_RenderPerformance. Sabemos por el decorador de métodos [PerformanceUnityTest] que se trata de una prueba de rendimiento de Unity .
Todas las pruebas del proyecto de prueba UnityPerformanceBenchmark siguen el mismo patrón que vemos en este método de prueba:
1. Cargar la escena para la prueba
2. Establezca la escena como activa para que podamos interactuar con ella en el método de prueba
3. Cree un objeto de prueba de tipo DynamicRenderPerformanceMonoBehaviourTest y agréguelo a la escena de prueba (esto sucede en el método SetupPerfTest<T>)
4. Espere un valor de tiempo constante para que la escena se “asiente” después de cargar y agregar el objeto de prueba a la escena antes de comenzar con las métricas de muestra.
5. Configurar nuestros marcadores de perfil para que los capture la API de extensión de prueba de rendimiento
6. Informe al equipo de prueba de rendimiento que estamos listos para comenzar a capturar métricas
7. Luego , yield el objeto de prueba (un IMonoBehaviourTest) para capturar métricas durante el bucle de renderizado.
También tomamos muestras de métricas personalizadas (métricas que no entran en ninguno de los marcadores del generador de perfiles de Unity , recuento de cuadros o tiempo de ejecución) en la clase base RenderPerformanceMonoBehaviourTestBase (esta clase hereda de MonoBehaviour).
Ejemplo: Muestreo de métricas personalizadas en un script de Monobehaviour
private void Update()
{
if (CaptureMetrics)
{
FrameCount++;
SampleFps();
#if ENABLE_VR
if (XRSettings.enabled)
{
SampleGpuTimeLastFrame();
}
#endif
}
if (IsMetricsCaptured)
{
EndMetricCapture();
}
}
private void SampleFps()
{
Fps = GetFps();
Measure.Custom(FpsSg, Fps);
startFrameCount = Time.renderedFrameCount;
}
private void SampleGpuTimeLastFrame()
{
var gpuTimeLastFrame = GetGpuTimeLastFrame();
Measure.Custom(GpuTimeLastFrameSg, gpuTimeLastFrame * 1000);
}
public void EndMetricCapture()
{
CaptureMetrics = false;
#if UNITY_ANALYTICS && UNITY_2018_2_OR_NEWER
Measure.Custom(startupTimeSg, appStartupTime);
#endif
}En el ejemplo anterior, capturamos FPS, GpuTimeLastFrame (si XR está habilitado) y el tiempo de inicio de la aplicación (si Unity Analytics está habilitado y estamos ejecutando Unity 2018.2 o más reciente, donde la API que necesitamos está disponible).
Finalmente, observe que en la misma clase base RenderPerformanceMonoBehaviourTestBase hemos implementado una propiedad public bool IsTestFinished. Debemos implementar esta propiedad porque nuestra RenderPerformanceMonoBehaviourTestBase implementa la interfaz IMonoBehaviourTest .
Esta propiedad es importante porque Unity Test Runner la utiliza para saber cuándo detener la prueba. Cuando su valor es verdadero la prueba finaliza. Depende de usted implementar la lógica que desee para determinar cuándo Unity Test Runner debe dejar de ejecutar la prueba.
Ejemplo: Muestreo de métricas personalizadas en la propiedad IsTestFinished
public bool IsTestFinished
{
get
{
bool isTestFinished = false;
if (IsMetricsCaptured)
{
Measure.Custom(objCountSg, RenderedGameObjects);
Measure.Custom(trianglesSg, Tris);
Measure.Custom(verticesSg, Verts);
isTestFinished = true;
}
return isTestFinished;
}
}En este ejemplo final, capturamos la cantidad de objetos de juego, triángulos y vértices renderizados en la escena cuando finaliza la prueba.
Ahora que hemos visto algunos ejemplos de cómo realizamos llamadas a la extensión de pruebas de rendimiento para muestrear métricas, hablemos sobre cómo las configuramos para empezar.
Los métodos Measure.* generalmente toman una estructura como parámetro llamada SampleGroupDefinition. Cuando creamos una nueva SampleGroupDefinition, definimos algunas propiedades para las muestras que estamos interesados en recopilar.
Ejemplo: Defina una nueva SampleGroupDefinition para GpuTimeLastFrame, utilizando milisegundos como unidad de muestra, agregue muestras utilizando un valor mínimo
A continuación se muestra SampleGroupDefinition para GpuTimeLastFrame. Así es como le permitimos a la extensión de pruebas de rendimiento saber cómo recopilar muestras y agregarlas para GpuTimeLastFrame.
Esta SampleGroupDefinition proviene del ejemplo de prueba de rendimiento de renderizado de escena dinámica, por lo que aquí hemos optado por agregar nuestras muestras utilizando el valor mínimo recopilado. Pero ¿por qué haríamos eso en lugar de utilizar una medida de agregación más común, como la mediana o el promedio?
La respuesta es porque la escena es dinámica. En una escena dinámica, el uso de una agregación mediana o promedio sería poco confiable o inconsistente para la misma escena ejecutada contra el mismo código dada la naturaleza cambiante de la representación. Probablemente esto sea lo mejor que podamos hacer si queremos rastrear un solo agregado para una métrica de renderizado en una escena dinámica. Sin embargo, cuando definimos una SampleGroupDefinition similar para nuestras escenas estáticas, definitivamente utilizamos una agregación mediana.
new SampleGroupDefinition(GpuTimeLastFrameName, SampleUnit.Millisecond, AggregationType.Min)
Ejemplo: Defina una nueva SampleGroupDefinition para FPS, utilizando ninguna como unidad de muestra, agregue muestras utilizando un valor mediano, un aumento en el valor es mejor
A continuación se muestra la SampleGroupDefinition para FPS (cuadros por segundo). FPS no tiene una unidad de medida separada; es simplemente FPS, por eso especificamos SampleUnit.None aquí. Aquí utilizaremos un tipo de agregación mediana; esto es en una escena estática, por lo que no tenemos que preocuparnos por una experiencia de renderizado impredecible. Estamos estableciendo explícitamente un umbral del 15% para el grupo de muestra y aprobamos como verdadero el argumento increaseIsBetter porque, si los FPS aumentan, ¡es algo bueno!
Estos dos últimos argumentos se recopilan y guardan en nuestro archivo .xml de resultados de pruebas de rendimiento cuando se ejecuta desde la línea de comandos, y se pueden usar más adelante en Unity Performance Benchmark Reporter para establecer puntos de referencia.
new SampleGroupDefinition(FpsName, SampleUnit.None, AggregationType.Median, threshold: 0,15, increaseIsBetter: verdadero)
Cuando se completa la prueba, la extensión de pruebas de rendimiento agrega todas las muestras de métricas que habilitamos anteriormente.
Quiero señalar que en nuestros ejemplos de código utilizamos un par de API de extensión de pruebas de rendimiento de Unity diferentes, a saber:
- Marcadores de medición y perfiladores
- Medida.Personalizada
La extensión de pruebas de rendimiento de Unity también proporciona otros métodos de medición que pueden adaptarse a sus necesidades específicas dependiendo de qué y cómo desee medir el rendimiento en Unity. Estos métodos adicionales incluyen:
- Método de medida
- Measure.Frames
- Medida.Alcance
- Measure.FrameTimes
Obtenga más información sobre los diferentes métodos de medición en la documentación de Unity Performance Testing Extension, específicamente en la sección “Toma de mediciones”.
Ahora que hemos visto algunos ejemplos de cómo escribimos pruebas de rendimiento utilizando Unity Test Runner mediante la extensión Unity Performance Testing, veamos cómo las ejecutamos.
Hay dos formas principales en las que podemos ejecutar nuestras pruebas de rendimiento
1. Desde la línea de comandos, inicie Unity con la opción -runTests . Esta es la forma preferida para las pruebas de rendimiento porque Unity Performance Test Extension generará un archivo .xml de resultados que podemos usar en Unity Performance Benchmark Reporter para ver y comparar nuestros resultados.
2. Directamente desde el Editor. Este es un enfoque útil si usted
a. Solo quiero ejecutar las pruebas y ver los resultados en la ventana Unity Test Runner sin necesidad de capturar los resultados para su uso posterior, o
b. ¿Quiere verificar que sus pruebas se ejecutarán o necesita depurar el código de prueba?
Aquí hay dos ejemplos de cómo ejecutar pruebas de rendimiento con Unity Test Runner desde la línea de comandos. Estos ejemplos deberían resultarle muy familiares, porque nos basamos en los mismos ejemplos que vimos anteriormente en nuestra discusión sobre cómo abrir el proyecto UnityPerformanceBenchmark desde la línea de comandos.
Ejemplo: Ejecución de pruebas de rendimiento de UnityPerformanceBenchmark desde Windows contra un reproductor Android
Aquí lanzamos Unity en Windows para compilar para Android con API de gráficos OpenGLES3, renderizado multiproceso y backend de scripting mono.
Unity.exe -runTests [-batchmode] -projectPath
C:\XRAutomatedTests-2018.2\PerformanceTests\UnityPerformanceBenchmark - Plataforma de prueba Android - buildTarget Android - playergraphicsapi=OpenGLES3 - mtRendering - scriptingbackend=mono - Resultados de prueba
C:\PerfTests\results\PerfBenchmark_Android_OpenGLES3_MtRendering_Mono.xml -logfile
C:\PerfTests\logs\PerfBenchmark_Android_OpenGLES3_MtRendering_Mono_UnityLog.txt
Ejemplo: Ejecución de pruebas de rendimiento de UnityPerformanceBenchmark desde OSX contra un reproductor iOS
Aquí lanzamos Unity en OSX para compilar para iOS con API de gráficos OpenGLES3, renderizado multiproceso y backend de scripting mono. También proporcionamos al equipo de desarrolladores de Apple y la información del perfil de aprovisionamiento necesaria para la implementación en un dispositivo iOS.
./ Unity -runTests [-batchmode] -projectPath /XRAutomatedTests-2018.2/PerformanceTests/UnityPerformanceBenchmark
-Plataforma de prueba iOS -buildTarget iOS -playergraphicsapi=OpenGLES3
-mtRendering -scriptingbackend=mono
-appleDeveloperTeamID=<yourAppleDeveloperTeamID>
-iOSProvisioningProfileID=<suIDdePerfilDeProvisionIos> -testResults /PerfTests/results/PerfBenchmark_Android_OpenGLES3_MtRendering_Mono.xml
-logfile /PerfTests/logs/PerfBenchmark_Android_OpenGLES3_MtRendering_Mono_UnityLog.txt
Para ambos ejemplos, hemos introducido tres o cuatro nuevas opciones de línea de comandos que nos ayudarán a ejecutar nuestras pruebas en lugar de simplemente abrir el Editor de Unity con los argumentos de línea de comandos disponibles para el método IPrebuildSetup.Setup.
-runTests
Esta opción le dice al Unity Test Runner que desea ejecutar sus pruebas
-testResults <pathToWritePerformanceTestResultsFile>
Esta opción especifica el nombre del archivo y la ruta al archivo .xml en el que Unity Test Runner debe guardar los resultados de las pruebas de rendimiento.
-logfile <pathToWriteUnityEditorLogFile>
Esta opción especifica el nombre del archivo y la ruta al archivo en el que el Editor de Unity debe escribir su registro. Esto es opcional, pero puede ser muy útil cuando estás investigando fallas y problemas si puedes acceder rápidamente al archivo de registro del Editor de Unity .
-modo por lotes
Esta opción forzará al Editor de Unity a abrirse en modo sin interfaz gráfica. Usamos esta opción cuando solo ejecutamos pruebas de rendimiento del jugador y no es necesario abrir la ventana del Editor de Unity . Esto puede ahorrar tiempo durante la ejecución de pruebas automatizadas. Cuando no se utiliza esta opción, el Editor de Unity se abrirá en la pantalla antes de ejecutar las pruebas.
En Unity ejecutamos nuestras pruebas de rendimiento desde la línea de comandos, a menudo en modo por lotes, en nuestro sistema de integración continua.
Ejemplo: Ejecución de pruebas de UnityPerformanceBenchmark desde la línea de comandos
Con la ventana Unity Test Runner abierta cerca de la parte superior cuando se selecciona PlayMode (las pruebas de PlayMode se ejecutan en el reproductor de compilación o en la ventana de modo de reproducción del Editor), tenemos
1. Ejecutar todo: haga clic en este botón para ejecutar todas las pruebas en la pestaña Modo de reproducción
2. Ejecutar seleccionado: haga clic en este botón para ejecutar la prueba o el nodo seleccionado y todas las pruebas debajo de él.
3. Ejecutar todo en el reproductor: haga clic aquí para que el Editor de Unity compile el tipo de reproductor configurado en la configuración de compilación y ejecute las pruebas allí
Requisito importante: ejecutar pruebas de rendimiento anteriores a la versión 0.1.50 de Performance Testing Extension en el Editor de Unity desde la ventana Test Runner no producirá un archivo .xml de resultados necesario para Unity Performance Benchmark Reporter. Sin embargo, si está utilizando la versión 0.1.50 o posterior de la extensión de pruebas de rendimiento, se escribirá un archivo results.xml en la carpeta del proyecto `Assets\StreamingAssets`.
Si está utilizando una versión de la extensión de pruebas de rendimiento anterior a la versión 0.1.50 y desea crear un archivo .xml de resultados cuando haya realizado sus pruebas de rendimiento, debe ejecutar las pruebas iniciando Unity desde la línea de comando con la opción de línea de comando -runTests. Sin embargo, tenga en cuenta que cuando ejecuta Unity con la opción de línea de comando -runTests, el Editor se abrirá y comenzará a ejecutar las pruebas.
Los archivos .xml de resultados contendrán los resultados y metadatos de las ejecuciones de pruebas que usaremos con Unity Performance Benchmark Reporter para crear resultados de referencia y compararlos con ejecuciones de pruebas posteriores.
Ejemplo: Ejecución de pruebas de rendimiento en el editor de Unity
Si ejecutamos estas pruebas desde el editor, los valores agregados se pueden ver cerca de la parte inferior de la ventana de Unity Test Runner al seleccionar cada prueba.
Ejemplo: Visualización de agregaciones de muestras de pruebas de rendimiento desde Unity Test Runner
Si desea ver los resultados de la ejecución de sus pruebas de rendimiento de Unity desde la línea de comandos, deberá utilizar Unity Performance Benchmark Reporter (o simplemente abrir el archivo .xml de resultados, pero no es una lectura fácil).
Con esto, pasemos a hablar sobre cómo podemos usar Unity Performance Benchmark Reporter para ver y comparar resultados.
Unity Performance Benchmark Reporter permite comparar las líneas base de métricas de rendimiento y las métricas de rendimiento posteriores (generadas mediante Unity Test Runner con Unity Performance Testing Extension) en un informe html con visualizaciones gráficas.
El reportero está construido como un ensamblaje .NET Core 2.x para que sea compatible y pueda ejecutarse en diferentes plataformas compatibles con .NET (Windows, OSX, etc.). Por lo tanto, para ejecutarlo, deberá asegurarse de haber instalado el SDK de .NET Core.
Para ejecutar el reportero Unity Performance Benchmark es necesario invocar el ensamblaje con el comando dotnet de la siguiente manera:
dotnet UnityPerformanceBenchmarkReporter.dll
--baseline=D:\UnityPerf\baseline.xml
--results=D:\UnityPerf\results --reportdirpath=d:\UnityPerf
Después de que se ejecute el reportero, se creará un directorio llamado UnityPerformanceBenchmark con un informe html y archivos .css, .js y de imagen de apoyo. Abra el informe html para ver visualizaciones de las métricas de rendimiento capturadas en los archivos de resultados .xml.
--resultados
La ruta a un directorio donde tenemos uno o más archivos .xml de resultados no base que se incluirán en el informe html.
Se debe pasar al menos un valor --results al ensamblado UnityPerformanceBenchmarkReporter.dll. Este es el único campo obligatorio.
Esta opción de línea de comando también se puede utilizar para especificar la ruta a un único archivo de resultados .xml que no sea de referencia. Además, puedes especificar varios directorios o archivos repitiendo la opción de la siguiente manera:
--results=D:\UnityPerf\results --results=D:\UnityPerf\results.xml
--baseline
La ruta a un archivo .xml de resultados que se utilizará al comparar otros resultados.
--reportdirpath
La ruta a un directorio donde el reportero creará el informe comparativo de rendimiento. Esto se crea en un subdirectorio de UnityPerformanceBenchmark.
Si no se especifica la ubicación del informe, se creará el subdirectorio UnityPerformanceBenchmark en el directorio de trabajo en el que se invocó UnityPerformanceBenchmarkReporter.dll.
Comparemos algunos resultados de pruebas de rendimiento con Performance Benchmark Reporter.
Ejemplo: Experimente con cambios de configuración en una escena de Gear VR habilitada para VR para mejorar la velocidad de cuadros
Tengo una escena de Unity con las siguientes características de complejidad.
- 732 objetos
- 95.898 triángulos
- 69.740 vértices
Ejecuté una prueba de rendimiento de Unity contra esta escena tomando métricas de muestreo que me ayudarían a comprender si podía mantener cerca de 60 FPS usando renderizado estéreo de múltiples pasadas. A continuación, ejecuté el Performance Benchmark Reporter con los resultados de mi prueba.
Lo que encontré es que mis FPS están más cerca de 30 FPS, la mitad de lo que me gustaría tener.
A continuación, intentaré utilizar la representación estéreo multivista de un solo paso para ver qué tan cerca de los 60 FPS puedo llegar. Volveré a ejecutar mi prueba de rendimiento con el cambio de configuración y luego crearé otro informe comparativo de rendimiento de Unity comparando mis primeros resultados con los nuevos.
Parece que el cambio de configuración a la representación multivista de un solo paso mejoró nuestros FPS a 37. Todavía necesitamos estar más cerca de los 60 FPS si queremos que esta escena se ejecute sin una caída significativa de cuadros en Gear VR.
Lo último con lo que voy a experimentar es reduciendo la cantidad de cubos giratorios en mi escena para ver si podemos aumentar los FPS .
Después de un par de intentos, puedo mejorar el rendimiento a ~55 FPS. Pero tuve que reducir el número de objetos en la escena de 732 a 31. Eso es bastante.
Volveré a hablar de otras mejoras que puedo realizar para optimizar el rendimiento, pero por ahora, usaré esto como base de FPS . Usaré esto como mi punto de referencia en el futuro, con la esperanza de mejorarlo si puedo.
Establecer puntos de referencia puede significar muchas cosas dependiendo de su proyecto. En este contexto, al ejecutar pruebas de rendimiento en Unity, hablamos de establecer un conjunto de resultados de referencia, un último conjunto conocido de métricas de rendimiento con el que podemos comparar resultados posteriores a medida que realizamos cambios. Estos se convierten en nuestro punto de referencia.
En la sección anterior llegué a una configuración que utiliza renderizado estéreo multivista de un solo paso para Gear VR y una cantidad reducida de objetos de escena, lo que resultó en un FPS“aceptable”. En ese momento decido usar los resultados de mi prueba como punto de referencia. Veamos un ejemplo de cómo podemos utilizar este punto de referencia a medida que realizamos más cambios en la configuración del reproductor.
Ejemplo: Utilice Performance Benchmark para detectar la regresión del rendimiento con cambios de configuración
Me gustaría habilitar el antialiasing en mi escena para suavizar la apariencia. La configuración de calidad predeterminada en Unity para Android deshabilita el antialiasing, pero me gustaría ver si podemos habilitarlo y aún así mantener un FPS aceptable para nuestra escena Gear VR .
Primero establezco el valor de antialiasing en mi método IPrebuildSetup.Setup en 4.
QualitySettings.antiAliasing = 4;
A continuación, vuelvo a ejecutar la prueba de rendimiento anterior en mi teléfono Android habilitado para Gear VR. Luego uso Unity Performance Benchmark Reporter para comparar esta nueva ejecución con mis resultados de referencia recientemente establecidos.
Pero mira, con la reconfiguración de mi reproductor Unity para usar antialiasing en el nivel 4, mis FPS cayeron a 32 FPS, que es aproximadamente donde comencé originalmente cuando creé esta escena con 732 objetos.
Me gustaría experimentar con algunos valores de antialiasing más bajos para ver si puedo recuperar un FPS aceptable para la escena antes de abandonar esta idea. Entonces, lo intento con el antialiasing configurado en 2 y luego finalmente en 1. Los resultados están en la imagen de abajo.
En este escenario de reconfiguración, utilizando el punto de referencia de rendimiento que establecí anteriormente, pude experimentar con cambios en la configuración de mi reproductor Unity y luego verificar los impactos en el rendimiento antes de comprometerme con ellos.
Aunque estoy dentro de mi umbral predeterminado de variación del 15 % para FPS usando el antialiasing establecido en 1, los FPS ahora están en 49, un poco demasiado lejos de los 60 FPS para mi escena habilitada para VR en la que me gustaría estar. No creo que me comprometa con estos cambios hoy.
Unity pone mucho énfasis en lograr un gran rendimiento de forma predeterminada. Pero Unity Engine es solo una parte de lo que en última instancia hace que a los usuarios les encante jugar sus juegos y disfruten de una experiencia fluida y de alto rendimiento en todas las plataformas en las que puedan jugar. Y los SDK, controladores o paquetes de Unity , por ejemplo, que funcionan muy bien sin introducir regresiones en el rendimiento son fundamentales para lograr una excelente experiencia de rendimiento general para todos.
Le he presentado un par de herramientas de Unity que facilitan el inicio de la recopilación de métricas de rendimiento y la creación de puntos de referencia con ellas: Unity Performance Testing Extension y Unity Performance Benchmark Reporter. Te animo a que experimentes lo que pueden hacer por ti y por tus esfuerzos centrados en el rendimiento.
Miramos a
- Cómo podemos usar Unity Test Runner para escribir pruebas de rendimiento para el generador de perfiles de muestra y otras métricas.
- Algunas formas diferentes en las que podemos ejecutar pruebas de rendimiento utilizando Unity Test Runner y
- Cómo utilizar Unity Performance Benchmark Reporter para analizar y comparar métricas de rendimiento, ejecución tras ejecución, a medida que comienza a mejorar sus pruebas de rendimiento.
Establecer líneas de base para estas métricas y usarlas para crear un punto de referencia para sus escenas, juegos, SDK, controladores, paquetes u otras integraciones de Unity puede ser una forma eficaz de comenzar a crear visibilidad sobre los impactos que tienen sus cambios. ¡Buena suerte!
Muchas gracias y crédito a mis colegas de Unity por su ayuda contribuyendo, intercambiando ideas, experimentando, desarrollando e iterando en este trabajo conmigo.
- Qi Jiang
- Sakari Pitkänen
- Gintautas Skersys
- Benjamín Smith