Por que o desempenho de 'Cities: Skylines 2' é ruim
(blog.paavo.me)- Cities: Skylines 2 é um jogo focado em simulação, mas em grande parte das situações apresenta um gargalo de GPU evidente, e benchmarks indicam que, para buscar 1080p a 60 FPS acima das configurações mínimas, é necessária uma placa de vídeo na faixa de 1000 a 2000 euros
- Um frame de exemplo capturado com o Renderdoc mostra 87,8 ms, 6705 draw calls, mais de 50 mil API calls e cerca de 6,7 GB de uso de buffers/texturas da GPU, ficando muito distante dos 16,7 ms exigidos para 60 FPS
- O núcleo do gargalo está na falta de LOD em muitos meshes e em um culling simples, fazendo com que geometrias de alto polígono que quase não contribuem para a imagem sejam renderizadas repetidamente; só o passe de sombras consome 40 ms e responde por 72% de todos os draw calls
- Os dentes dos cidadãos, que viraram polêmica, de fato são renderizados, mas não são a causa única; o problema maior é o acúmulo de contagem excessiva de vértices e renderização ineficiente em modelos de cidadãos, props e objetos decorativos em geral
- A integração entre Unity DOTS e HDRP ainda parece imatura, e há indícios de que a Colossal Order implementou por conta própria a ligação entre ECS e renderer, culling, virtual texturing e outros elementos; isso reduziu gargalos de CPU, mas o pipeline gráfico aparenta não ter sido refinado o suficiente
Problemas de desempenho expostos antes e depois do lançamento
- Antes do lançamento, Cities: Skylines 2 já havia mostrado aumento dos requisitos recomendados, adiamento da versão de console para 2024 e restrições a comentários sobre desempenho
- Uma semana antes do lançamento, a Colossal Order publicou um aviso que soava quase como uma explicação antecipada sobre os problemas de desempenho, e depois do lançamento a performance virou alvo quase universal de críticas
- Jogos de construção de cidades podem naturalmente ter dificuldade para atingir altas taxas de quadros, mas neste título o destaque vai para o gargalo de GPU, e não para o gargalo de CPU mais comum no gênero
- Segundo benchmarks da PC Games Hardware e da Gamers Nexus, para obter 1080p a 60 FPS em configurações acima de “very low”, seria necessária uma GPU na faixa de 1000 a 2000 euros
- Em um sistema com RTX 3080, Ryzen 7 5800X e monitor 5120×1440, a primeira execução ficou abaixo de 10 FPS no menu principal; ao desativar depth of field, motion blur e volumetric effects, como recomendado pela desenvolvedora, o desempenho subiu para cerca de 90 FPS
- Em um mapa vazio, o jogo rodou em cerca de 30 a 40 FPS e, mesmo após cerca de uma hora de jogo, permaneceu em nível semelhante com travamentos ocasionais
Estrutura do motor e da renderização
- Cities: Skylines 2 é baseado em Unity 2022.3.7 e usa DOTS, ECS e o compilador Burst da Unity
- Graças ao DOTS, o jogo aparentemente utiliza vários núcleos de CPU com muito mais eficiência do que o antecessor
- A lógica do jogo é composta, no código, por cerca de 1200 sistemas, e praticamente toda a lógica parece estar apoiada na estrutura ECS
- A UI não usa o Unity UI Toolkit, e sim o Coherent Gameface, baseado em HTML, CSS e JavaScript
- O bundle de JS mostra indícios do uso de React e Webpack
- A UI pode ter vantagens em manutenção e ajustes, mas nos dados analisados não aparece como gargalo principal
- Os gráficos usam Direct3D 11 e o HDRP da Unity
- Para conectar um jogo feito com DOTS/ECS ao sistema de renderização tradicional da Unity, é necessária uma camada adicional, mas Cities: Skylines 2 aparentemente não usa Unity Entities Graphics
- O skinning e o occlusion culling do Entities Graphics estão marcados como experimentais
- Não há suporte a virtual texturing
- Em vez disso, o jogo parece implementar sua própria camada de integração com
BatchRendererGroupe código de baixo nível
Ambiente e limitações da análise com Renderdoc
- A análise de renderização foi feita com Renderdoc
- A versão do Game Pass não permitia que Renderdoc e NVidia Nsight Graphics acessassem o executável, por causa de sandboxing ou permissões de arquivo
- Na versão da Steam, a combinação do Paradox Launcher com o fluxo de autenticação da Steam também dificultou a conexão do Renderdoc pelos métodos comuns, e a captura só foi possível com o Global Process Hook do Renderdoc
- O NVidia Nsight Graphics funcionou ao abrir a Steam dentro do Nsight e iniciar o jogo a partir dali, mas no D3D11 muitos recursos de profiling não são suportados, então ele não trouxe mais informação do que o Renderdoc
- O frame analisado foi capturado em uma cidade com cerca de 1000 habitantes
- A versão do jogo era
1.0.11f1 - O patch mais recente,
1.0.12f1, inclui algumas melhorias, mas não resolve todos os problemas - O tempo de frame medido pelo Renderdoc foi de 87,8 ms, equivalente a cerca de 11,4 FPS
- Como durante o jogo real a média era de 30 a 40 FPS, pode haver sobrecarga do Renderdoc ou o frame capturado pode ter sido um outlier
- A versão do jogo era
Métricas de renderização do frame de exemplo
- As estatísticas do frame de exemplo reportadas pelo Renderdoc são as seguintes
- Draw calls: 6705
- Dispatch calls: 191
- API calls: 53361
- Index/vertex bind calls: 8724
- Constant bind calls: 25006
- Resource update calls: 1679
- Textures: 342, cerca de 3926 MB
- Render targets: 180, cerca de 2328 MB
- Buffers: 4144, cerca de 447 MB
- Total de buffers e texturas da GPU: cerca de 6,7 GB
- O uso de 6,7 GB de VRAM é alto para uma cena relativamente simples, e ainda existem GPUs intermediárias da geração atual com 8 GB de VRAM
- Segundo uma análise adicional no FAQ, renderizar esse frame envolveu 121 milhões de input vertices e cerca de 36 milhões de rasterized triangles
- Isso não representa o total de polígonos realmente visíveis na tela, mas sim toda a geometria processada em todos os passes de renderização
- Há relatos no Reddit de cidades maiores atingindo centenas de milhões de vértices e, em situações específicas, até 1 bilhão de vértices por frame
Instancing com DOTS e atualização de dados na GPU
- Quase todos os draw calls usam instancing
- O jogo armazena em um único buffer grande os dados de instância necessários para renderizar todos os objetos
- Objetos comuns parecem usar cerca de 50 floats por instância, enquanto estradas usam ainda mais dados
- Os dados de instância de todos os objetos visíveis são atualizados no buffer e enviados para a GPU a cada frame
- O buffer começa com cerca de 60 MB e é realocado para tamanhos maiores quando necessário
- Esse buffer é usado em quase todos os draw calls e, segundo o Renderdoc, fica acessível tanto no vertex shader quanto no pixel shader
- Isso pode gerar custo de consulta em todos os vértices, agravando o problema dos meshes com muitos polígonos
Simulação e virtual texturing
- Os compute shaders da GPU são usados para simulações ligadas aos gráficos, como água, neve, partículas e animação esquelética
- Esses trabalhos somam cerca de 1,5 ms, menos de 2% do tempo total do frame
- A hipótese inicial de que a simulação principal do jogo seria fortemente descarregada para a GPU não se sustenta à luz do código decompilado e das GPU calls
- Cities: Skylines 2 aparentemente implementa seu próprio sistema de virtual texturing/streaming de texturas
- O Streaming Virtual Texturing nativo da Unity continua experimental e sem suporte
- O jogo parece usar virtual texturing na maioria dos objetos 3D estáticos, exceto no terreno
- O virtual texturing pode economizar memória ao carregar apenas os tiles de textura necessários, mas na implementação atual há problemas em que texturas de alta resolução não carregam nem mesmo em superfícies próximas
- A falta de suporte a anisotropic texture filtering também pode estar ligada ao uso de virtual texturing
- Esse passe leva cerca de 0,5 ms
Custo dos principais passes de renderização
-
Geração do skybox
- Usa o sistema de céu fisicamente baseado do Unity HDRP para gerar um cubemap a cada frame
- Leva cerca de 0,65 ms, o que representa quase 4% do orçamento de frame para 60 FPS
-
Pre-pass
- Primeira etapa do deferred rendering, grava depth, normal e informações estimadas de smoothness em texturas separadas
- Leva cerca de 8,2 ms, sendo um passe muito pesado
-
Motion vectors
- Renderiza em um passe separado os vetores de movimento por pixel usados em anti-aliasing e motion blur
- Leva cerca de 0,6 ms
- Os motion vectors parecem parcialmente quebrados, o que ajuda a explicar a ausência de suporte a DLSS e FSR2 no momento da análise
-
Estradas e decals
- Renderiza estradas, grama e elementos que acompanham a superfície do terreno
- Leva cerca de 1 ms
-
Main pass
- É o passe central do deferred rendering, usando os buffers gerados até ali e o cache de virtual textures para produzir albedo, normal, propriedades PBR, depth etc.
- As informações de visibilidade do virtual texturing também são geradas aqui
- Aparentemente ele é renderizado com metade da resolução horizontal, enquanto o terreno é renderizado em resolução total sem usar virtual texturing
- Leva cerca de 16,7 ms, exatamente o tempo total disponível para um frame a 60 FPS
-
Ambient occlusion
- Pelo nome de debug do shader, parece usar GTAO
- Leva cerca de 1,6 ms
-
SSR + SSGI
- Usa screen space reflections e screen space global illumination do Unity HDRP
- Os dois efeitos juntos consomem cerca de 3 ms
-
Deferred lighting
- Combina os buffers intermediários gerados antes para produzir um resultado próximo da imagem final
- Leva cerca de 2,1 ms
-
Renderização da água
- Usa pré-processamento com compute shader e imagens reduzidas/borradas como entrada para renderizar a superfície da água
- Leva cerca de 1 ms
-
Pós-processamento
- Usa temporal AA, bloom, tonemapping e, quando ativados, DOF e motion blur
- No total consome cerca de 1 a 2 ms
-
UI
- Renderiza a UI baseada em Gameface e textos dentro do mundo
- Os nomes de ruas são renderizados com signed distance fields 2D e usam o depth buffer para se misturar à cena quando ficam atrás de construções
- O tempo do passe final de UI é desprezível
A polêmica dos dentes e os modelos de personagens
- Os personagens cidadãos realmente têm um modelo completo de dentes, embora isso não seja visível na perspectiva normal do jogo
- A partir da análise de Hexcoder0 no NVidia Nsight Graphics, no Reddit, ficou conhecido que os dentes eram renderizados sempre na qualidade máxima
- O problema mais importante é que os meshes ligados aos personagens em geral não têm variantes de LOD
- A Colossal Order reconheceu publicamente esse problema e também mencionou uma questão mais ampla no tratamento de LOD
- Os modelos de cidadãos são gerados com base no Didimo Popul8, e o modelo de dentes/boca do jogo tem 6108 vertices, acima dos 1060 vertices do mesh padrão da Didimo
- Um único personagem, sem contar cabelo, roupa e acessórios, chega a cerca de 56 mil vertices
- Um prédio residencial de baixa densidade médio, excluindo objetos de quintal e detalhes, fica abaixo de 10 mil vertices
- No frame de exemplo, 13 conjuntos de dentes são renderizados, mas não afetam um único pixel da imagem final
- Os dentes não são a causa isolada da queda de desempenho; são mais uma evidência de que há geometria desnecessária demais em toda a cena
Props com muitos polígonos e problemas de culling
- O jogo renderiza objetos demais com contagem de polígonos alta demais, mesmo quando eles contribuem pouco ou nada para a imagem final
- Há duas causas principais
- Alguns modelos não têm variantes de LOD
- O sistema próprio de culling é simples e aparentemente só implementa frustum culling, sem sinais de occlusion culling
- Existe culling por distância, mas ele não é agressivo; isso reduz pop-in, porém prejudica o desempenho
- Exemplos de props com muitos polígonos identificados na análise
- Palete com botijões de gás: mais de 17 mil vertices
- Varal de roupas: 25 mil vertices por unidade, e a variante mais densa passa de 30 mil vertices
- Guarita de estacionamento: mais de 40 mil vertices, sem LOD, com até os cabos de monitor e teclado modelados individualmente
- Pilha de toras: mais de 100 mil vertices
- Combinar prédios e props internos em um único mesh reduz draw calls, mas impede o culling individual dos objetos internos
- Em um jogo de construção de cidades, o mesmo modelo ineficiente pode ser renderizado centenas de vezes em um único frame, fazendo pequenos desperdícios se acumularem rapidamente
- O problema não é simplesmente a existência de modelos em alta resolução, e sim o fato de o jogo não conseguir lidar com esse nível de detalhe e usar polígonos de forma ineficiente e inconsistente
O passe de sombras é o maior gargalo
- Cities: Skylines 2 usa cascaded shadow mapping
- As sombras apresentam muitos artefatos e flickering, especialmente quando o sol ou as folhas das árvores se movem
- O jogo usa 4 cascades, cada uma com resolução de 2048×2048
- Existe uma opção avançada de resolução do directional shadow map, mas no código analisado ela não está conectada a nada
- Nem as opções individuais nem a configuração geral de shadow quality alteram a resolução do shadow map
- Os presets medium e high são, na prática, idênticos
- O preset low desativa as sombras projetadas pelo terreno
- Apesar da baixa qualidade, o shadow mapping consome cerca de 40 ms e é o passe de renderização mais lento
- Dos 6705 draw calls do frame de exemplo, 4828, ou 72%, são usados no shadow mapping
- O jogo aparentemente trata todos os objetos 3D como potenciais shadow casters em todos os níveis de qualidade, independentemente do tamanho ou da distância
- Nos contadores de desempenho do Renderdoc, muitos draw calls afetam menos de 100 pixels, ou até zero, no shadow map, e os dentes também reaparecem no passe de sombras
- Melhorias em LOD e culling podem ter grande impacto também no desempenho do shadow mapping
- Como detalhe positivo, o jogo calcula a posição do sol e da lua usando a data, hora e coordenadas atuais da cidade
Problema de desempenho no menu principal
- O menu principal parece ter apenas uma imagem de fundo estática e botões, mas na prática há sempre uma cena 3D presente
- Por trás do menu é renderizada uma cena com terreno, água e skybox, que depois é totalmente coberta pela UI
- Como o pipeline completo de renderização é usado mesmo para essa cena invisível, as configurações gráficas afetam imediatamente também o desempenho do menu principal
- No lançamento, a maioria das configurações vinha por padrão perto do máximo, incluindo efeitos pesados que a própria desenvolvedora recomendou desativar
- Ainda assim, a causa de a primeira execução ter caído para algo em torno de 7 FPS não foi totalmente esclarecida
- Essa mesma queda de desempenho não foi reproduzida depois
- Na primeira execução, o cache de virtual textures é processado, mas não foi confirmado se isso usa a GPU
- A cena inteira do menu principal contém cerca de 400 draw calls, 563 mil input vertices e 745 mil rasterized triangles
Interpretação complementada no FAQ
- É difícil afirmar categoricamente que o jogo deveria ter sido feito em Unreal Engine 5
- A UE5 tem Nanite, Lumen e Virtual Shadow Maps, que poderiam lidar com parte dos problemas vistos em C:S2
- Por outro lado, faltam recursos em nível de produção equivalentes ao Unity ECS para lógica de jogo e simulação em grande escala, e uma estrutura centrada em C++ pode ser pior em flexibilidade e acessibilidade para mods
- O jogo não é totalmente desprovido de LOD
- Muitos prédios parecem ter LOD adequado
- Já elementos como canos, props de quintal e objetos decorativos muitas vezes não têm LOD ou não selecionam o LOD corretamente
- O InstaLOD aparentemente é usado no asset pipeline do jogo, especialmente ao importar novos assets nas ferramentas de mod, e não na renderização em tempo de execução
- A UI baseada em JavaScript não aparece como gargalo principal nos dados analisados
- O Gameface não é baseado em um motor de navegador completo como o Electron, mas em um framework customizado para UI de jogos
- A explicação é que ele deve ter vantagem de memória e desempenho em relação a soluções baseadas em Chromium/Blink ou WebKit
- O Renderdoc tem limitações como ferramenta de benchmark preciso, mas oferece evidências suficientes para entender “o que o jogo está fazendo para ficar lento”
Conclusão: menos gargalo de CPU, mas um pipeline de GPU quase inacabado
- A razão direta de Cities: Skylines 2 ser pesado demais para a GPU é que ele envia geometria desnecessária demais para a placa de vídeo
- Esse desperdício de geometria vem da falta de LOD em muitos meshes e de uma implementação de culling simples e pouco ajustada
- O motivo de existir uma camada própria de culling e integração com renderização parece ser que a integração entre Unity DOTS e HDRP ainda estava em andamento e tinha limitações importantes para uso em um jogo real
- O virtual texturing da Unity também continua em estado experimental, então a Colossal Order implementou sua própria solução, que ainda mostra sinais de baixa maturidade
- A leitura mais plausível é que a Colossal Order apostou nas novas tecnologias da Unity, como DOTS, e obteve ganhos em gargalos de CPU e escala da simulação, mas em gráficos precisou implementar por conta própria sistemas como culling, animação e streaming de texturas
- A alegação da desenvolvedora de que o jogo foi pensado desde o início para 30 FPS é vista com ceticismo, e considerada difícil de justificar para um jogo exclusivamente de PC e com essa qualidade gráfica
- As áreas com maior potencial de correção são adicionar LOD, melhorar o culling, otimizar a seleção de shadow casters e reorganizar assets em nível de props; como muitos assets podem precisar de ajustes individuais, isso deve levar tempo
1 comentários
Opiniões do Hacker News
É um texto interessante, então eu gostaria que a discussão se concentrasse em o que, especificamente, é interessante
Threads assim facilmente acabam virando generalizações sobre o próprio
$THING, neste caso o jogo como um todo, ou sobre$RELATED, aqui os frameworks, ou sobre assuntos semelhantes em geralEm princípio isso não é ruim, mas a cada passo rumo à generalização a discussão fica mais rasa e menos interessante. É por isso que as diretrizes do site incluem “evite discussões tangenciais genéricas” - https://news.ycombinator.com/newsguidelines.html
O trecho dizendo que “o motivo de a Colossal Order não usar o culling embutido do Unity e ter sua própria implementação é que a integração do Unity com DOTS e HDRP ainda está em pleno andamento e pode ser considerada inadequada para a maioria dos jogos reais, então eles tiveram que implementar diretamente boa parte da parte gráfica” infelizmente bate com minha experiência com as ferramentas do Unity
DOTS foi lançado, mas dá a sensação de que a implementação está sendo deixada de lado, como outras ferramentas que a Unity adquiriu. A gestão da empresa está seriamente errada e, olhando para o caso da política de preços que explodiu publicamente algumas semanas atrás, parece que estão mais focados em arrancar mais dinheiro dos usuários do que em melhorar o engine
A implementação de ECS do Bevy é realmente boa, e espero que ela, junto com o Godex, tenha sucesso nessa área
A coerência de cache na camada de gameplay não consegue corrigir gargalos no nível do engine
Por exemplo, Godot não é centrado em ECS; ele gira em torno do conceito de “servidores”, subsistemas autônomos de jogo que tratam de forma majoritariamente independente áreas especializadas como renderização e física, e que são fracamente acoplados à lógica normal do jogo
A arquitetura ECS nasceu da época do PS2/PS3, quando as CPUs eram péssimas. Por causa de caches pequenos, alto custo de falhas de previsão de desvio, memória lenta, espaços de memória fragmentados e ausência de armazenamento de acesso aleatório, os desenvolvedores precisavam criar jogos seguindo padrões previsíveis de acesso à memória, e o resultado comum era uma estrutura que processava dados do jogo em pequenos blocos via streaming
Esse método ainda é, em geral, uma boa prática, mas com CPUs ultrarrápidas, excelente execução especulativa, bons preditores de desvio e dezenas de MB de cache, ele já não é mais uma exigência rígida. Isso é ainda mais verdadeiro considerando que os jogos modernos não aumentaram tanto assim a escala do que acontece na tela em relação a 10 ou 20 anos atrás. Em jogos de ação, ainda é raro o jogador lutar contra mais de uma dúzia de inimigos ao mesmo tempo
Jogos com milhares de elementos simultâneos na tela normalmente precisam de lógica e processamento especializados separados
Uma dica para quem pretende jogar este jogo: basta mudar o dimensionamento de resolução de dinâmico para fixo
Na minha 3080, o menu principal saiu de “10 fps injogáveis” para “roda sem problemas” dentro do jogo, em opções médio-altas
Como referência, lembro que um frame de Crysis, na cena de benchmark, tinha algo em torno de 300 mil vértices ou triângulos. Então isso daria algo como 3 a 10 pilhas de toras, dependendo de para que lado minha memória está errada e de quão ruim é a proporção vértices/triângulos de cada modelo
Edit: verifiquei a contagem de vértices e polígonos com RenderDoc. A cena de exemplo do texto processa 121 milhões de vértices e mais de 40 milhões de triângulos
Gostei muito do estilo de escrita:
frases como “Este passe é surpreendentemente pesado, porque leva cerca de 8,2 milissegundos, ou seja, aproximadamente um tempo absurdamente longo…”
“Essa malha de pilha de toras também só é usada no passe de renderização de sombras, mas tem mais de 100 mil vértices”… mas por quê?
É completamente normal que jogos AAA tenham alguns elementos incompletos e não otimizados. O orçamento é sempre limitado e o prazo de desenvolvimento é curto. Além disso, é uma indústria dependente de sucessos de bilheteria sem garantia de resultado. Há algumas formas de aumentar a chance de sucesso de um jogo, mas em geral elas estão mais próximas da gestão do que do desenvolvimento, e as previsões de receita de pré-venda não costumam acertar. Então é preciso fazer concessões para reduzir riscos, cortar custos onde for possível e rebaixar as prioridades de desenvolvimento mais caras. Essas concessões são muito maiores do que uma única malha não otimizada. Uma malha não é nada
É um fato curioso que essa malha seja LOD0 e que a malha dos dentes também seja LOD0. Mas isso, por si só, não derruba a performance do jogo, e também parece improvável que corrijam isso em vez de fazer ajustes reais de performance. A obsessão desta thread com essas malhas parece um pouco exagerada
Há muitos comentários emocionalmente carregados, então não quero acrescentar mais a isso; só estou tentando dar mais contexto
É correto resumir dizendo que o jogo usa modelos extremamente detalhados, mas não tem uma forma inteligente de abstrair ou fazer culling do que não vai aparecer de fato como pixels?
E, se for isso mesmo, é algo fácil de corrigir, ou é tão central à arquitetura que, para resolver, seria preciso redesenhar tudo desde o projeto?
O “truque” em si deve ser bem conhecido, mas não acho que a implementação seja fácil
DOTS veio das ideias de Mike Action. Basta ver a apresentação dele na CppCon 2014, “Data-Oriented Design and C++” [1]. Porém, segundo o Twitter, Mike saiu da Unity
[1] https://www.youtube.com/watch?v=rX0ItVEVjHc
Se houvesse o Nanite da UE5, talvez desse para aguentar de algum jeito, mas uma geometria tão excessiva desse nível teria derrubado todo o resto
Passei 40 minutos no Proton Experimental tentando tirar mais do que alguns fps até mesmo em um mapa vazio a 1080p, mas desisti e pedi reembolso. Se corrigirem o desempenho horrível, penso em tentar de novo
Eu me diverti muito com o primeiro, então é uma pena enorme não poder jogar este
“Se você estiver enfrentando problemas de desempenho, recomendamos reduzir a resolução da tela para 1080p, desativar a profundidade de campo e os volumétricos, e reduzir a iluminação global enquanto trabalhamos para resolver os problemas que afetam o desempenho”
Foi só isso que fiz para obter um desempenho fluido em uma AMD Radeon RX 5700 XT