Projeto Hades enfim chegou promete revolucionar o emulador Yuzu fiz o teste em 19 jogos ....
Teste em 19 jogos...O que é o Projeto Hades?
Projeto Hades é o codinome para a reescrita do código do nosso descompilador de sombreador, embora neste ponto ele tenha se tornado muito mais do que isso.
Para aqueles que não sabem o que é um descompilador de sombreador, você precisará entender o processo de como os jogos renderizam (mostram / exibem) qualquer coisa. Shaders são programas especiais que são codificados para executar várias tarefas em GPUs, geralmente relacionadas à renderização de gráficos em exibição. Os sombreadores são geralmente escritos em linguagens de sombreador de alto nível compatíveis com a API gráfica em uso - por exemplo, OpenGL Shading Language (GLSL) , Standard Portable Intermediate Representation - V (SPIR-V) e OpenGL ARB Assembly language (GLASM) . Os jogos costumam usar centenas ou milhares desses sombreadores para informar à GPU o que renderizar e como fazer.
No caso dos jogos Switch, eles também usam shaders para renderizar gráficos no próprio Switch. No entanto, uma vez que esses shaders são pré-compilados para a GPU do Switch, yuzu não pode usá-los diretamente para renderizar gráficos usando a GPU host (GPU do usuário). Portanto, primeiro o yuzu descompila esses sombreadores em algo chamado IR, ou Representação Intermediária , que é então usado para gerar os sombreadores GLSL / SPIR-V / GLASM de alto nível usados pelas APIs gráficas e drivers para renderizar jogos na GPU host.
A descompilação do shader é o processo de traduzir o código de máquina da GPU convidado (neste caso, o Nintendo Switch) para uma representação que pode ser compilada na GPU hospedeira (PC do usuário). A compilação de shader é o processo de pegar essa representação e enviá-la ao driver da GPU host para ser compilada e executada na GPU do usuário.
Metas
O principal objetivo do Projeto Hades era redesenhar o código de geração de decompilador e shader com foco na simplicidade e precisão. O objetivo era tornar a descompilação e a compilação mais rápidas em geral, melhorando assim o desempenho. Reescrever o descompilador nos permitiria auditá- lo por meio de testes de unidade , seguindo um design semelhante ao dinármico , permitindo a análise adequada do programa e otimizações sobre a representação intermediária de emissão rápida.
Pegando uma folha do livro do dynarmic, os desenvolvedores optaram por usar uma representação SSA , já que funcionaria muito bem com o SPIR-VIR usado para shaders, graças ao seu suporte nativo para SSA. Quanto aos testes de unidade, Rodrigo escreveu testes caseiros para o hardware que ajudaram os desenvolvedores a emular com precisão o comportamento do hardware.
Mas isso foi só o começo. Ao longo de alguns meses, os desenvolvedores iriam enfrentar e superar muitos obstáculos com a reescrita do código e os objetivos do projeto seriam expandidos para acomodar muito mais.
Visão geral das mudanças
O Projeto Hades foi um esforço colaborativo dos desenvolvedores Rodrigo , Blinkhawk e epicboy . Eles distribuíram o trabalho necessário entre si e passaram horas incontáveis em codificação, teste de unidade, teste de jogo e validação de desempenho.
Blinkhawk trabalhou principalmente na implementação de instruções diversas, incluindo instruções de amostragem de textura necessárias para descompilação. Ele adicionou suporte para Nvidia VertexA shader stage, um estágio de sombreador não padrão disponível no hardware Nvidia que é executado antes do normal VertexB shader stage.
Isso permitiu que jogos como Catherine: Full Body, Bravely Default 2e A Hat in Timerenderizassem gráficos pela primeira vez. Blinkhawk também corrigiu um problema no cache de textura do yuzu relacionado ao streaming de textura usado em jogos Unreal Engine 4 (UE4), resolvendo muitos de seus problemas de renderização.
Observação: devido a uma condição de corrida em nossa Emulação de GPU, para renderizar Catherine Full Body corretamente, pode ser necessário desativar a Emulação de GPU assíncrona.
O epicboy implementou quase todas as instruções aritméticas, lógicas e de ponto flutuante, além de desenvolver todo o backend GLSL. GLSL é o backend padrão, quando a API OpenGL é selecionada nas configurações do yuzu.
A reescrita do backend GLSL não fazia parte do plano inicial para o Project Hades, já que os desenvolvedores pretendiam apenas trabalhar no GLASM e no SPIR-V , mas foi incluída posteriormente devido à lentidão e erros de alguns compiladores OpenGL SPIR-V . Dito isso, alguns drivers OpenGL se beneficiam muito do uso de sombreadores SPIR-V , então a escolha de usar SPIR-V no OpenGL é deixada como uma configuração experimental.
Mario e Rabbids
Rodrigo projetou a estrutura geral para suportar essas mudanças e desenvolveu vários passos de otimização para melhorar o desempenho sempre que possível. Além disso, ele reescreveu todo o back-end do GLASM (GL Assembly) e integrou os rasterizadores de front-end existentes aos novos back-ends.
O backend GLASM é um caminho especial onde os shaders descompilados ( linguagem assembly ) ignoram as etapas de compilação de shaders na GPU host, melhorando assim o desempenho. Infelizmente, o GLASM é suportado apenas por GPUs Nvidia, limitando o escopo deste aumento de desempenho.
Embora essas tenham sido as principais mudanças, também houve muitas outras pequenas melhorias. Mudar como os shaders são gerados também significava mudar a maneira como as informações do shader são apresentadas aos renderizadores. Isso foi revisado para simplificar, o que levou a alguns novos recursos e facilidade de armazenamento em cache.
Vulkan Pipeline Caching
Todas as informações necessárias para gerar pipelines do zero agora são armazenadas em cache no disco, removendo assim a trepidação do shader quase completamente no Vulkan. Em contraste, o OpenGL ainda pode encontrar travamentos de sombreador devido a mudanças de estado imprevisíveis ou não documentadas. Vulkan ainda pode ter travamentos menores quando novos sombreadores são detectados, mas não foram notados durante nossos testes.
Criação de pipeline assíncrona
yuzu já suportado Asynchronous Shaders, em que as chamadas de desenho são ignoradas (a renderização é pausada) até que o sombreador, ou no caso de Vulkan, o pipeline, seja compilado. Isso é bom em alguns casos porque permite sessões de jogo mais consistentes, minimizando a gagueira de compilações de sombreador. Mas isso também tem uma grande desvantagem: introduz falhas gráficas, que às vezes são persistentes durante a sessão de jogo. Embora isso não seja um problema após reiniciar a emulação e ter os sombreadores em cache, não é o ideal.
A melhor maneira de implementar isso para Vulkan era construir pipelines em paralelo sem pular as chamadas de desenho. Em outras palavras, continue processando comandos da GPU enquanto os pipelines estão sendo construídos. Isso permite construir um pipeline por thread da CPU (menos um) em paralelo enquanto o jogo está sendo executado. Isso resulta em gagueira reduzida que é, de certa forma, semelhante a pular chamadas de desenho.
Como é que isso funciona?
Para entender por que isso é possível, é necessário explicar como funciona a gravação do comando Vulkan do yuzu. Os comandos são registrados e adiados para um thread separado para processamento (às vezes chamado de "thread de envio de comando (CS)").
Este thread é executado em paralelo ao thread principal da GPU. Isso significa que o encadeamento CS pode construir os pipelines sequencialmente enquanto o encadeamento GPU principal continua sua execução, enviando periodicamente novos comandos para o encadeamento CS.
Infelizmente, isso não é possível no momento em OpenGL, porque os drivers esperam mais frequentemente por seu thread CS do que yuzu em seu próprio thread CS. Pode ser possível se otimizarmos todo o backend OpenGL para evitar chamadas "glGen *" e "glGetSynciv" em uma chamada draw.
Ainda mais!!
Além dessas grandes melhorias, também temos muitas otimizações menores. Alguns notáveis estão listados abaixo:
O Project Hades controla o número de bytes usados em buffers constantes e passa essas informações para o cache de buffer. Isso reduz o número de bytes carregados em alguns títulos, melhorando assim o desempenho.
O envio do comando Vulkan à GPU agora acontece no thread CS separado, aumentando o desempenho em 1 a 2 FPS Super Mario Odyssey, embora a apresentação na tela ainda esteja sendo sincronizada.
Sincronização para buffers de textura entre o cache de textura e o cache de buffer, corrigindo alguns travamentos em jogos Koei Tecmo.
Gere pools de descritores Vulkan especializados, compartilhando pools em pipelines semelhantes. Isso reduz o consumo de memória e o tempo de inicialização na maioria dos drivers, economizando aproximadamente 700 MiB de VRAM na AMD em comparação com a abordagem anterior.
Uso de VK_KHR_push_descriptor quando disponível. Reduz a sobrecarga de atualização de conjuntos de descritores na Nvidia em 57% e em 10% na Intel (medido em Super Smash Bros. Ultimate1v1 no destino final). Também reduz o consumo de memória, mas isso não foi medido.
Uso de VK_EXT_conservative_rasterization e VK_EXT_provoking_vertex quando disponível.
Use funções especializadas de "pré-desenho" por pipeline para reduzir o trabalho desnecessário.
Texture Reaper, que limpa os recursos menos usados em sua VRAM para reduzir o uso de VRAM. Abordaremos este e outros, em detalhes, em nosso próximo relatório de progresso.
Correções gráficas
Graças ao redesenho e reimplementação de todo o nosso código de geração de shaders, os desenvolvedores foram capazes de investigar e identificar as causas de falhas gráficas em muitos jogos. Na verdade, alguns jogos como Yoshi's Crafted World, Trials of Mana, Minecraft Dungeons, e muitos outros, agora tornar quase perfeitamente. The Legend of Zelda: Breath of the Wildagora é totalmente jogável no Vulkan.
Bem! Vamos falar de números agora!
O Projeto Hades reescreveu a grande maioria do código da GPU e fez toneladas de melhorias e otimizações para aumentar o desempenho. Como as mudanças afetaram muitas áreas da emulação de GPU, observamos melhorias de desempenho em muitos títulos.
Abaixo estão alguns gráficos de comparação de desempenho entre yuzu Early Access (1860) e Project Hades em nossas especificações recomendadas usando a API Vulkan. Observe que, no momento da comparação, o EA 1860 era quase equivalente ao yuzu Mainline, sem alterações que afetariam significativamente o desempenho.
Isso não é tudo. As melhorias feitas no back-end Vulkan no Projeto Hades melhoraram muito o desempenho para usuários de GPU AMD no Linux (RADV).
Estes são apenas um pequeno testamento das melhorias de desempenho que Hades traz. Estaremos compartilhando mais gráficos de desempenho com nosso próximo relatório de progresso.
Fin
Nossos esforços de desenvolvimento foram enormemente acelerados por nossos testadores, que testaram dezenas de títulos para bugs, correções e regressões de desempenho. Uma vez que nossos testes não puderam cobrir todos os títulos de forma realista, solicitamos que você teste e jogue seus jogos favoritos no yuzu e experimente você mesmo as melhorias. Durante o teste, se você encontrar regressões, falhas, bugs ou travamentos, entre em contato conosco por meio de nossos canais Discord Patreon. Isso nos ajudará a identificar e corrigir quaisquer problemas potenciais que o Projeto Hades possa apresentar.
Isso é tudo que temos por agora, até a próxima! Feliz emulação!