Comparação de desempenho no Unity: Como começar
Como desenvolvedor Unity , você quer que seus usuários amem jogar seus jogos, aproveitando uma experiência tranquila em todas as plataformas em que jogarem. E se eu dissesse que acabamos de facilitar a criação de benchmarks de desempenho? Se você quer aprender a desenvolver jogos ou ferramentas Unity pensando no desempenho, continue lendo!
Neste post, explico como usar algumas ferramentas do Unity que oferecem uma maneira fácil de começar a coletar métricas de desempenho e criar benchmarks com elas: o Unity Test Runner que vem com o Unity Editor, o Unity Performance Testing Extensione o Unity Performance Benchmark Reporter.
Como desenvolvedor Unity , você pode se encontrar na seguinte situação: seu projeto estava rodando rápido e sem problemas há pouco tempo, mas então uma ou mais mudanças ocorreram e agora as cenas estão visivelmente lentas, os quadros estão caindo e outros problemas de desempenho começaram a aparecer. Pode ser difícil rastrear quais mudanças levaram à regressão do desempenho.
Se você for um parceiro da Unity , vai querer entender as mudanças de desempenho em seus SDKs, drivers, plataformas, pacotes ou outros artefatos. Ou você gostaria de coletar métricas de desempenho em diferentes versões do Unity com seus produtos, mas não está muito claro como fazer isso e depois fazer as comparações.
Esses são apenas alguns exemplos em que estabelecer parâmetros de desempenho pode realmente salvar o dia. Agora, deixe-me mostrar como você pode começar a coletar métricas de desempenho, criar benchmarks com elas e visualizar mudanças nas métricas de desempenho.
Para esta discussão, veremos o código de teste no projeto de teste de desempenho de exemplo UnityPerformanceBenchmark.
Baixe a versão mais recente do XRAutomatedTests do GitHub. Você encontrará o projeto UnityPerformanceBenchmark no subdiretório PerformanceTests.
O projeto UnityPerformanceBenchmark contém uma variedade de cenas de amostra que, por sua vez, são usadas em testes de desempenho do Unity usando a extensão de teste de desempenho do Unity .
A primeira coisa que faremos é dar uma olhada em como escrevemos testes de desempenho usando o Unity Test Runner com a extensão Unity Performance Testing. Aqui estão algumas informações básicas sobre ambas as ferramentas antes de prosseguirmos.
Estamos usando o Unity Test Runner para executar nossos testes de desempenho. O Unity Test Runner é uma estrutura de execução de testes incorporada ao Unity Editor, permitindo que você teste seu código nos modos Editar e Reproduzir em players de plataforma de destino, como Standalone, Android ou iOS. Se você não estiver familiarizado com o Unity Test Runner, confira a documentação do Unity Test Runner.
A extensão Unity Performance Testing é um pacote do Unity Editor que fornece uma API e atributos de caso de teste que permitem que você experimente e agregue marcadores do criador de perfil do Unity e métricas personalizadas que não são do criador de perfil, no Unity Editor e nos players. Você pode aprender mais conferindo a documentação da extensão Unity Performance Testing, mas veremos alguns exemplos aqui.
A extensão do teste de desempenho do Unity requer o Unity 2018.1 ou superior. Certifique-se de usar o Unity versão 2018.1 ou superior se quiser executar os testes de desempenho de amostra no projeto UnityPerformanceBenchmark ou sempre que estiver usando a extensão de teste de desempenho do Unity .
O projeto UnityPerformanceBenchmark implementa a interface IPrebuildSetup , um recurso do Unity Test Runner, onde podemos implementar um método Setup que é chamado automaticamente antes que a execução do teste seja executada pelo Unity Test Runner.
A primeira coisa que o método IPrebuildSetup.Setup do projeto UnityPerformanceBenchmark faz é analisar os argumentos da linha de comando em busca das configurações de compilação do player. Isso nos permite construir o player de forma flexível para nossos testes de desempenho usando o mesmo projeto Unity em diferentes plataformas, modos de processamento de renderização, APIs gráficas do player, implementações de script e configurações habilitadas para XR, como caminho de renderização estéreo e SDKs de VR .
Portanto, precisaremos abrir o projeto UnityPerformanceBenchmark com o Unity a partir da linha de comando, passando as opções de compilação do player que queremos usar quando executarmos os testes no Unity Test Runner.
Exemplo: Inicie o projeto UnityPerformanceBenchmark no Windows para criar o Android Player:
Unity.exe -projectPath
C:\XRAutomatedTests-2018.2\PerformanceTests\UnityPerformanceBenchmark
-testPlatform Android -buildTarget Android -playergraphicsapi=OpenGLES3 -mtRendering -scriptingbackend=mono
Aqui, lançamos o Unity no Windows para criar para Android com API gráfica OpenGLES3, renderização multithread e backend de script mono.
Exemplo: Inicie o projeto UnityPerformanceBenchmark do OSX para construir o player iOS
./Unity -projectPath /XRAutomatedTests-2018.2/PerformanceTests/UnityPerformanceBenchmark
-testPlatform iOS -buildTarget iOS -playergraphicsapi=OpenGLES3 -mtRendering -scriptingbackend=mono
-appleDeveloperTeamID=<yourAppleDeveloperTeamID>
-iOSProvisioningProfileID=<yourIosProvisionProfileID>
Aqui lançamos o Unity no OSX para construir para iOS com API gráfica OpenGLES3, renderização multithread e backend de script mono. Também fornecemos à equipe de desenvolvedores da Apple e as informações de perfil de provisionamento necessárias para implantação em um dispositivo iOS.
Quando abrimos o projeto UnityPerformanceBenchmark com o Unity a partir da linha de comando, como nos exemplos acima, os argumentos da linha de comando estarão na memória para o método IPrebuildSetup.Setup analisar e usar para construir o player.
Embora essa abordagem de inicialização a partir da linha de comando não seja necessária para executar testes no Unity Test Runner, é um bom padrão a ser usado para evitar o uso de um projeto de teste separado para cada configuração de player.
Detalhei as opções de linha de comando para abrir o projeto, ou apenas executar os testes, a partir da linha de comando no wiki para o projeto de teste: Como executar os testes de benchmark de desempenho do Unity. Para saber mais sobre como estamos analisando as configurações de compilação do player no projeto de teste, dê uma olhada no arquivo RenderPerformancePrebuildStep.cs no diretório Scripts do projeto de teste UnityPerformanceBenchmark.
Depois de abrir o UnityPerformanceBenchmark, precisamos abrir a janela Unity Test Runner no Unity Editor
- no Unity 2018.1, vá para Janela > Executor de Teste.
- no Unity 2018.2, vá para Janela > Geral > Executor de Testes.
A janela do Unity Test Runner será aberta e se parecerá com a imagem abaixo.
Estes são nossos testes de desempenho do Unity . Podemos executá-los no Editor usando o botão Executar no canto superior esquerdo da janela, ou no dispositivo ou plataforma real usando o botão “Executar tudo no player” no canto superior direito da janela.
Dica de depuração
Se você quiser depurar o código no seu método IPrebuildSetup.Setup
1. Defina pontos de interrupção no seu código IPrebuildSetup.Setup no Visual Studio
2. Anexar ao Unity Editor com a extensão Visual Studio Tool for Unity
3. Execute seus testes no Editor usando o botão “Executar tudo” ou “Executar selecionado” na janela Unity Test Runner.
Neste ponto, o depurador do Visual Studio invadirá seu código, onde você poderá depurar conforme necessário.
Vamos dar uma olhada em um exemplo de teste de desempenho para que possamos entender melhor como ele funciona.
Exemplo: Amostragem de marcadores do Profiler em um teste de desempenho do 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);
}Neste exemplo, nosso método de teste é chamado SpiralFlame_RenderPerformance. Sabemos pelo decorador de métodos [PerformanceUnityTest] que este é um teste de desempenho do Unity .
Todos os testes no projeto de teste UnityPerformanceBenchmark seguem o mesmo padrão que vemos neste método de teste:
1. Carregue a cena para o teste
2. Defina a cena como ativa para que possamos interagir com ela no método de teste
3. Crie um objeto de teste do tipo DynamicRenderPerformanceMonoBehaviourTest e adicione-o à cena de teste (isso acontece no método SetupPerfTest<T>)
4. Aguarde um valor constante de tempo para que a cena se “estabilize” após carregar e adicionar o objeto de teste à cena antes de iniciarmos as métricas de amostra.
5. Configure nossos marcadores de profiler para captura pela API de extensão de teste de desempenho
6. Deixe o teste de desempenho saber que estamos prontos para começar a capturar métricas
7. Em seguida, yield retorna o objeto de teste (um IMonoBehaviourTest) para capturar métricas durante o loop de renderização.
Também amostramos métricas personalizadas (métricas que não se enquadram em nenhum dos marcadores do criador de perfil do Unity , contagem de quadros ou tempo de execução) na classe base RenderPerformanceMonoBehaviourTestBase (essa classe herda de MonoBehaviour).
Exemplo: Amostragem de métricas personalizadas em um script de monocomportamento
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
}No exemplo acima, estamos capturando FPS, GpuTimeLastFrame (se o XR estiver habilitado) e o tempo de inicialização do aplicativo (se o Unity Analytics estiver habilitado e estivermos executando no Unity 2018.2 ou mais recente, onde a API necessária está disponível).
Por fim, observe na mesma classe base RenderPerformanceMonoBehaviourTestBase que implementamos uma propriedade public bool IsTestFinished. Somos obrigados a implementar essa propriedade porque nossa RenderPerformanceMonoBehaviourTestBase implementa a interface IMonoBehaviourTest .
Essa propriedade é importante porque o Unity Test Runner a utiliza para saber quando parar o teste. Quando seu valor for verdadeiro, o teste termina. Cabe a você implementar a lógica desejada para determinar quando o Unity Test Runner deve parar de executar o teste.
Exemplo: Amostragem de métricas personalizadas na propriedade 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;
}
}Neste exemplo final, estamos capturando o número de objetos de jogo, triângulos e vértices renderizados na cena quando o teste termina.
Agora que vimos alguns exemplos de como fazemos chamadas para a Performance Testing Extension para obter métricas de amostra, vamos falar sobre como configurá-las para começar.
Os métodos Measure.* geralmente recebem uma struct como parâmetro chamada SampleGroupDefinition. Quando criamos uma nova SampleGroupDefinition, definimos algumas propriedades para as amostras que estamos interessados em coletar.
Exemplo: Defina um novo SampleGroupDefinition para GpuTimeLastFrame, usando milissegundos como unidade de amostra, agregue amostras usando um valor mínimo
Abaixo está o SampleGroupDefinition para GpuTimeLastFrame. É assim que informamos à Performance Testing Extension como coletar amostras e agregá-las para GpuTimeLastFrame.
Esta SampleGroupDefinition é do exemplo de teste de desempenho de renderização de cena dinâmica, então aqui escolhemos agregar nossas amostras usando o valor mínimo coletado. Mas por que faríamos isso em vez de usar uma medida de agregação mais comum, como mediana ou média?
A resposta é porque a cena é dinâmica. Em uma cena dinâmica, usar uma agregação mediana ou média seria pouco confiável ou inconsistente para a mesma cena executada no mesmo código, dada a natureza mutável da renderização. Provavelmente, isso é o melhor que podemos fazer se quisermos rastrear um único agregado para uma métrica de renderização em uma cena dinâmica. Entretanto, quando definimos um SampleGroupDefinition semelhante para nossas cenas estáticas, definitivamente usamos uma agregação mediana.
new SampleGroupDefinition(GpuTimeLastFrameName, SampleUnit.Millisecond, AggregationType.Min)
Exemplo: Defina uma nova SampleGroupDefinition para FPS, usando none como unidade de amostra, agregue amostras usando um valor mediano, um aumento no valor é melhor
Abaixo está o SampleGroupDefinition para FPS (Quadros por Segundo). FPS não tem uma unidade de medida separada; é apenas FPS, então especificamos SampleUnit.None aqui. Usaremos um tipo de agregação mediana aqui; isso ocorre em uma cena estática, então não precisamos nos preocupar com uma experiência de renderização imprevisível. Estamos estabelecendo explicitamente um limite de 15% para o grupo de amostra e passando true para o argumento increaseIsBetter porque, se o FPS aumenta, é uma coisa boa!
Esses dois últimos argumentos são coletados e salvos em nosso arquivo .xml de resultados de teste de desempenho quando executados na linha de comando e podem ser usados posteriormente no Unity Performance Benchmark Reporter para estabelecer benchmarks.
novo SampleGroupDefinition(FpsName, SampleUnit.None, AggregationType.Median, limite: 0,15, increaseIsBetter: verdadeiro)
Quando o teste é concluído, todas as amostras de métricas que habilitamos anteriormente são agregadas pela Extensão de Teste de Desempenho.
Quero salientar que em nossos exemplos de código usamos algumas APIs diferentes de extensão de teste de desempenho do Unity , a saber:
- Medida.ProfilerMarkers e
- Medida.Personalizado
A extensão Unity Performance Testing também fornece outros métodos de medição que podem atender às suas necessidades específicas, dependendo do que e como você deseja medir o desempenho no Unity. Esses métodos adicionais incluem:
- Medida.Método
- Medida.Quadros
- Medida.Escopo
- Medida.TemposDeQuadro
Saiba mais sobre os diferentes métodos de medição na documentação da extensão Unity Performance Testing, especificamente na seção “Fazendo medições”.
Agora que vimos alguns exemplos de como escrevemos testes de desempenho usando o Unity Test Runner com a Unity Performance Testing Extension, vamos ver como os executamos.
Existem duas maneiras principais de executar nossos testes de desempenho
1. Na linha de comando, inicie o Unity com a opção -runTests . Essa é a maneira preferida para testes de desempenho porque a extensão de teste de desempenho do Unity gerará um arquivo .xml de resultado para nós, que podemos usar no Unity Performance Benchmark Reporter para visualizar e comparar nossos resultados.
2. Diretamente do Editor. Esta é uma abordagem útil se você
a. Deseja apenas executar os testes e visualizar os resultados na janela Unity Test Runner sem precisar capturar os resultados para uso posterior, ou
b. Quer verificar se seus testes serão executados ou precisa depurar no código de teste.
Aqui estão dois exemplos de como executar testes de desempenho com o Unity Test Runner a partir da linha de comando. Esses exemplos devem parecer muito familiares, porque estamos construindo a partir dos mesmos exemplos que vimos anteriormente em nossa discussão sobre abrir o projeto UnityPerformanceBenchmark a partir da linha de comando.
Exemplo: Executando os testes de desempenho do UnityPerformanceBenchmark do Windows em um player Android
Aqui, lançamos o Unity no Windows para criar para Android com API gráfica OpenGLES3, renderização multithread e backend de script mono.
Unity.exe -runTests [-batchmode] -projectPath
C:\XRAutomatedTests-2018.2\Testes de desempenho\UnityPerformanceBenchmark -testPlatform Android -buildTarget Android -playergraphicsapi=OpenGLES3 -mtRendering -scriptingbackend=mono -testResults
C:\PerfTests\results\PerfBenchmark_Android_OpenGLES3_MtRendering_Mono.xml -logfile
C:\PerfTests\logs\PerfBenchmark_Android_OpenGLES3_MtRendering_Mono_UnityLog.txt
Exemplo: Executando testes de desempenho do UnityPerformanceBenchmark do OSX em um player iOS
Aqui lançamos o Unity no OSX para construir para iOS com API gráfica OpenGLES3, renderização multithread e backend de script mono. Também fornecemos à equipe de desenvolvedores da Apple e as informações de perfil de provisionamento necessárias para implantação em um dispositivo iOS.
./ Unity -runTests [-batchmode] -projectPath /XRAutomatedTests-2018.2/Testes de Desempenho/UnityPerformanceBenchmark
-testPlatform iOS -buildTarget iOS -playergraphicsapi=OpenGLES3
-mtRenderização -scriptingbackend=mono
-appleDeveloperTeamID=<yourAppleDeveloperTeamID>
-iOSProvisioningProfileID=<seuIosProvisionProfileID> -testResults /PerfTests/results/PerfBenchmark_Android_OpenGLES3_MtRendering_Mono.xml
-logfile /PerfTests/logs/PerfBenchmark_Android_OpenGLES3_MtRendering_Mono_UnityLog.txt
Para ambos os exemplos, introduzimos três a quatro novas opções de linha de comando que nos ajudarão a executar nossos testes em vez de apenas abrir o Editor do Unity com os argumentos de linha de comando disponíveis para o método IPrebuildSetup.Setup.
-runTests
Esta opção informa ao Unity Test Runner que você deseja executar seus testes
-testResults <pathToWritePerformanceTestResultsFile>
Esta opção especifica o nome do arquivo e o caminho para o arquivo .xml no qual o Unity Test Runner deve salvar os resultados dos seus testes de desempenho.
-logfile <pathToWriteUnityEditorLogFile>
Esta opção especifica o nome do arquivo e o caminho para o arquivo no qual o Editor do Unity deve gravar seu registro. Isso é opcional, mas pode ser muito útil quando você estiver investigando falhas e problemas se puder acessar rapidamente o arquivo de log do Unity Editor.
-modo de lote
Esta opção forçará o Editor Unity a abrir no modo headless. Usamos essa opção quando estamos apenas executando testes de desempenho do player e não há necessidade de abrir a janela do Editor do Unity . Isso pode economizar tempo durante a execução de testes automatizados. Quando esta opção não for usada, o Unity Editor será aberto na tela antes de executar os testes.
Na Unity, executamos nossos testes de desempenho na linha de comando, geralmente em modo de lote, em nosso sistema de integração contínua.
Exemplo: Executando os testes UnityPerformanceBenchmark na linha de comando
Com a janela Unity Test Runner aberta perto do topo quando o PlayMode é selecionado (os testes do PlayMode são executados no build player ou na janela do playmode do Editor), temos
1. Executar tudo - clique neste botão para executar todos os testes na guia PlayMode
2. Executar selecionado - clique neste botão para executar o teste ou nó selecionado e todos os testes abaixo dele.
3. Executar tudo no player - clique aqui para que o Unity Editor crie o tipo de player configurado nas configurações de compilação e execute os testes lá
Requisito importante: executar testes de desempenho anteriores à versão 0.1.50 da Performance Testing Extension no Unity Editor a partir da janela Test Runner não produzirá um arquivo .xml de resultado necessário para o Unity Performance Benchmark Reporter. Entretanto, se você estiver usando a versão 0.1.50 ou posterior da Performance Testing Extension, um arquivo results.xml será gravado na pasta do projeto `Assets\StreamingAssets`.
Se você estiver usando uma versão do Performance Testing Extension anterior à versão 0.1.50 e quiser criar um arquivo .xml de resultado quando tiver feito seus testes de desempenho, será necessário executar os testes iniciando o Unity na linha de comando com a opção de linha de comando -runTests. Esteja ciente, no entanto, de que quando você estiver executando o Unity com a opção de linha de comando -runTests, o Editor será aberto e começará a executar os testes.
Os arquivos .xml de resultado conterão os resultados e metadados das execuções de teste que usaremos com o Unity Performance Benchmark Reporter para criar resultados de benchmark e comparar com execuções de teste subsequentes.
Exemplo: Executando testes de desempenho no Unity Editor
Se estivermos executando esses testes dentro do editor, os valores agregados poderão ser vistos perto da parte inferior da janela do Unity Test Runner selecionando cada teste.
Exemplo: Visualizando agregações de amostra de teste de desempenho do Unity Test Runner
Se quiser ver os resultados da execução dos seus testes de desempenho do Unity na linha de comando, você precisará usar o Unity Performance Benchmark Reporter (ou apenas abrir o arquivo .xml de resultado, mas não é uma leitura fácil).
Com isso, vamos falar sobre como podemos usar o Unity Performance Benchmark Reporter para visualizar e comparar resultados.
O Unity Performance Benchmark Reporter permite a comparação de linhas de base de métricas de desempenho e métricas de desempenho subsequentes (conforme geradas usando o Unity Test Runner com a Unity Performance Testing Extension) em um relatório HTML com visualizações gráficas.
O repórter é criado como um assembly .NET Core 2.x para que seja compatível e executado em diferentes plataformas suportadas pelo .NET (Windows, OSX, etc.). Portanto, para executá-lo, você precisará garantir que instalou o .NET Core SDK.
Executar o relator do Unity Performance Benchmark envolve invocar o assembly com o comando dotnet como este:
dotnet UnityPerformanceBenchmarkReporter.dll
--baseline=D:\UnityPerf\baseline.xml
--results=D:\UnityPerf\results --reportdirpath=d:\UnityPerf
Após a execução do repórter, um diretório chamado UnityPerformanceBenchmark será criado com um relatório HTML e arquivos .css, .js e de imagem de suporte. Abra o relatório HTML para visualizar visualizações das capturas de métricas de desempenho nos arquivos de resultados .xml.
--resultados
O caminho para um diretório onde temos um ou mais arquivos .xml de resultados não básicos a serem incluídos no relatório HTML.
Pelo menos um valor --results deve ser passado para o assembly UnityPerformanceBenchmarkReporter.dll. Este é o único campo obrigatório.
Esta opção de linha de comando também pode ser usada para especificar o caminho para um único arquivo de resultado .xml não-baseline. Além disso, você pode especificar vários diretórios ou arquivos repetindo a opção assim:
--results=D:\UnityPerf\results --results=D:\UnityPerf\results.xml
--linha de base
O caminho para um arquivo .xml de resultado que será usado ao comparar outros resultados.
--reportdirpath
O caminho para um diretório onde o repórter criará o relatório de benchmark de desempenho. Isso é criado em um subdiretório UnityPerformanceBenchmark.
Se o local do relatório não for especificado, o subdiretório UnityPerformanceBenchmark será criado no diretório de trabalho em que o UnityPerformanceBenchmarkReporter.dll foi invocado.
Vamos comparar alguns resultados de testes de desempenho com o Performance Benchmark Reporter.
Exemplo: Experimente com alterações de configuração em uma cena de VR com Gear VR habilitado para melhorar a taxa de quadros
Tenho uma cena do Unity com as seguintes características de complexidade.
- 732 objetos
- 95.898 triângulos
- 69.740 vértices
Executei um teste de desempenho do Unity com base nessas métricas de amostragem de cena que me ajudariam a entender se eu conseguiria manter perto de 60 FPS usando renderização estéreo multipassagem. Em seguida, executei o Performance Benchmark Reporter com os resultados do meu teste.
O que descobri é que meu FPS está mais próximo de 30 FPS, metade do que eu gostaria.
Em seguida, tentarei usar o Single Pass Multiview Stereo Rendering para ver o quão próximo de 60 FPS consigo chegar. Executarei novamente meu teste de desempenho com a alteração de configuração e, em seguida, criarei outro relatório de benchmark de desempenho do Unity comparando meus primeiros resultados com os novos.
Parece que a mudança de configuração para renderização Single Pass Multiview melhorou nosso FPS para 37. Ainda precisamos estar mais próximos de 60 FPS se quisermos que esta cena rode sem queda significativa de quadros no Gear VR.
A última coisa que vou experimentar é reduzir o número de cubos giratórios na minha cena para ver se conseguimos aumentar o FPS .
Depois de algumas tentativas, consegui melhorar o desempenho para ~55 FPS. Mas tive que reduzir o número de objetos na cena de 732 para 31. Isso é bastante.
Voltarei a falar sobre outras melhorias que posso fazer para otimizar o desempenho, mas, por enquanto, usarei isso como uma base de FPS . Usarei isso como referência daqui para frente, na esperança de melhorá-lo se possível.
Estabelecer benchmarks pode significar muitas coisas dependendo do seu projeto. Neste contexto, ao executar testes de desempenho no Unity, estamos falando sobre estabelecer um conjunto de resultados de base, um último conjunto conhecido como bom de métricas de desempenho com o qual podemos comparar resultados subsequentes à medida que fazemos alterações. Elas se tornam nossa referência.
Na seção anterior, cheguei a uma configuração usando Single Pass Multiview Stereo Rendering para Gear VR e uma contagem reduzida de objetos de cena, o que resultou em um FPS“aceitável”. Nesse ponto, decido usar os resultados dos meus testes como referência. Vamos ver um exemplo de como podemos usar esse benchmark à medida que fazemos mais alterações na configuração do player.
Exemplo: Use o benchmark de desempenho para detectar regressão de desempenho com alterações de configuração
Gostaria de habilitar o antialiasing na minha cena para suavizar a aparência. As configurações de qualidade padrão no Unity para Android desabilitam o antialiasing, mas gostaria de ver se podemos habilitá-lo e ainda manter um FPS aceitável para nossa cena do Gear VR .
Primeiro, defino o valor de antialiasing no meu método IPrebuildSetup.Setup como 4.
QualitySettings.antiAliasing = 4;
Em seguida, executei novamente o teste de desempenho anterior no meu telefone Android com Gear VR. Em seguida, uso o Unity Performance Benchmark Reporter para comparar essa nova execução com meus resultados de benchmark recém-estabelecidos.
Mas veja, com a reconfiguração do meu player Unity para usar antialiasing no nível 4, meu FPS caiu para 32 FPS, que é mais ou menos onde comecei quando criei esta cena com 732 objetos.
Gostaria de experimentar alguns valores mais baixos de antialiasing para ver se consigo recuperar um FPS aceitável para a cena antes de desistir dessa ideia. Então, tento definir o antialiasing como 2 e, finalmente, como 1. Os resultados estão na imagem abaixo.
Neste cenário de reconfiguração, usando o benchmark de desempenho que estabeleci anteriormente, consegui experimentar alterações nas configurações do meu player Unity e, então, verificar os impactos no desempenho antes de aplicá-los.
Embora eu esteja dentro do meu limite padrão de 15% de variação para FPS usando o antialiasing definido como 1, o FPS agora está em 49, um pouco longe dos 60 FPS para minha cena habilitada para VR, onde eu gostaria de estar. Acho que não vou me comprometer com essas mudanças hoje.
A Unity está colocando muito foco em ótimo desempenho por padrão. Mas o Unity Engine é apenas parte do que, no final das contas, faz com que os usuários adorem jogar seus jogos, desfrutando de uma experiência suave e de alto desempenho em todas as plataformas em que podem jogar. E SDKs, drivers ou pacotes Unity , por exemplo, que funcionam muito bem sem introduzir regressões de desempenho são essenciais para uma ótima experiência geral de desempenho para todos.
Apresentei a você algumas ferramentas do Unity que facilitam a coleta de métricas de desempenho e a criação de benchmarks com elas: a Unity Performance Testing Extension e o Unity Performance Benchmark Reporter. Eu encorajo você a experimentar o que eles podem fazer por você e por seus esforços focados no desempenho.
Nós olhamos para
- Como podemos usar o Unity Test Runner para escrever testes de desempenho para amostrar profiler e outras métricas,
- Algumas maneiras diferentes de executar testes de desempenho usando o Unity Test Runner e
- Como usar o Unity Performance Benchmark Reporter para analisar e comparar métricas de desempenho, execução após execução, à medida que você começa a aprimorar seus testes de desempenho.
Estabelecer linhas de base para essas métricas e usá-las para criar um benchmark para suas cenas, jogos, SDK, drivers, pacotes ou outras integrações do Unity pode ser uma maneira eficaz de começar a criar visibilidade sobre os impactos que suas alterações têm. Boa sorte!
Muitos agradecimentos e créditos aos meus colegas da Unity pela ajuda contribuindo, fazendo brainstorming, experimentando, desenvolvendo e iterando neste trabalho comigo.
- Qi Jiang
- Sakari Pitkänen
- Gintautas Skersys
- Benjamin Smith