- Minecraft Java Edition está mudando o motor de renderização gráfica de OpenGL para Vulkan
- A mudança é motivada pela interrupção das atualizações do OpenGL e pelo fim do suporte no macOS
- O Vulkan tem suporte nativo no Windows e Linux; no macOS, será suportado por uma camada de tradução, sem perda de desempenho
- Com a transição, espera-se melhora na qualidade visual e na taxa de quadros
- OpenGL e Vulkan serão testados em paralelo nas snapshots e, quando a estabilidade for garantida, o OpenGL deverá ser removido
Bringing modern rendering to Java
- O trabalho de preparação para o Vibrant Visuals no Minecraft: Java Edition continua, com refatoração e modernização do código de renderização em andamento
- Atualizações anteriores já melhoraram a estrutura do código de renderização
- Agora o projeto entra na fase de substituir a própria base tecnológica de renderização
- Está prevista a transição da tecnologia de renderização do jogo de OpenGL para Vulkan
- O objetivo é abrir novas possibilidades em gráficos e desempenho
- A mudança deve impactar a comunidade de mods e alguns jogadores
What are we changing?
- Atualmente, a Java Edition usa a API gráfica OpenGL, criada nos anos 1990
- Desde o lançamento, o jogo permanece baseado em OpenGL
- O motivo para a adoção do OpenGL foi a possibilidade de suporte a Linux, Windows e macOS
- O jogo foi projetado para rodar em praticamente qualquer PC ou Mac
- O OpenGL deixou de receber atualizações há 9 anos, está em estado de deprecated no macOS e deverá deixar de funcionar no futuro
- Para manter a compatibilidade com o macOS, era preciso continuar preso a uma versão antiga do OpenGL, o que dificultava modernizar a base de código
- Para que a Java Edition continue rodando na maioria dos PCs, incluindo macOS e Linux, a transição para fora do OpenGL se tornou necessária
Introducing: Vulkan
- O Vulkan é uma API gráfica usada no mercado há mais de 10 anos e adotada pelos principais fabricantes de hardware
- Tem suporte nativo no Windows e nas versões modernas de Linux; no macOS, pode ser usado por meio de uma camada de tradução, funcionando sem perda de desempenho
- No longo prazo, isso abre espaço para melhorias de desempenho e expansão de recursos
- Também fornece a base necessária para implementar o Vibrant Visuals
- Caso a GPU tenha mais de 10 anos, existe a possibilidade de ela não oferecer suporte ao Vulkan
What does this mean for modders?
- A transição de OpenGL para Vulkan vai afetar modos de renderização baseados em OpenGL
- O trabalho de migração para Vulkan deve exigir mais esforço do que uma adaptação para um lançamento comum
- A recomendação para a comunidade de mods é reduzir a dependência de OpenGL
- Também é recomendado reutilizar ao máximo as APIs internas de renderização
- Se necessário, é possível discutir questões técnicas diretamente com a equipe de desenvolvimento
- As discussões técnicas acontecem no canal do Discord de Vibrant Visuals
- Não é um canal de anúncios, mas um espaço para discussões técnicas aprofundadas entre desenvolvedores
What does this mean for players?
- Alguns mods podem ser afetados durante o processo de transição
- Os criadores desses mods precisarão de tempo para atualizar seus projetos
- Em snapshots futuras, OpenGL e Vulkan serão oferecidos em paralelo
- Será possível escolher o renderizador tanto nas snapshots quanto nas versões finais
- O trabalho de estabilidade e redução de bugs seguirá em paralelo
- Os bugs devem ser reportados em bugs.mojang.com
When is this happening?
- A meta é introduzir o Vulkan nos testes de snapshot durante o verão
- Durante o período de testes, será possível alternar entre OpenGL e Vulkan
- Quando a estabilidade e o desempenho forem validados, a implementação de OpenGL deverá ser removida
- Haverá aviso prévio antes da remoção
- Os requisitos mínimos de sistema também deverão ser atualizados
Vulkan and Vibrant Visuals
- A modernização do renderizador é uma etapa central do roadmap do Vibrant Visuals
- A transição para Vulkan amplia a margem para melhorias gráficas e reforça a capacidade de desempenho
- Também há expectativa de redução de bugs relacionados a drivers
- Um objetivo central é garantir a continuidade do funcionamento no macOS
- Assim, jogadores de todos os sistemas operacionais compatíveis poderão continuar participando em igualdade de condições
Significado da atualização
- Esta transição é um passo importante para levar o Minecraft Java a uma stack moderna de tecnologias gráficas
- Ela fortalece a base técnica do motor do jogo, criando uma estrutura mais favorável para expansão futura e adição de recursos
- A migração de OpenGL para Vulkan também acompanha a troca geracional das APIs gráficas em toda a indústria de jogos
3 comentários
Comentários do Hacker News
Espero que, com o tempo, o overhead de CPU na thread principal diminua
Jogos portados de DX11 para 12 e de OpenGL para Vulkan não ganharam desempenho apenas pela troca de API, mas por aproveitarem a capacidade de processar draw calls em paralelo
No Minecraft, a CPU acaba virando gargalo antes da GPU conseguir renderizar no máximo, então espero que essa mudança também traga mais folga de CPU em ambientes com mods
Por curiosidade, rodei a versão de Windows pelo Proton e o desempenho melhorou 30%
Acho que isso se deve ao multithreading da biblioteca dxvk usada pelo Proton
Acho uma escolha razoável que o Minecraft Java Edition, por ser exclusivo de desktop, possa evitar os problemas de drivers Vulkan no mobile
Ainda assim, para uma empresa do porte da Microsoft, eu imaginava que haveria capacidade para criar uma RHI multiplataforma usando APIs estáveis por plataforma (DX12, Metal)
Manter três versões do renderizador em Java seria um peso enorme, especialmente porque o ecossistema de mods é central, e só essa mudança já deve causar bastante confusão
Não acho que valha a pena dificultar ainda mais a manutenção dos mods de shader
Dá para rodar Vulkan também no macOS, então não vejo muito motivo para usar DX12 em um projeto novo
No meu velho Acer C720 Chromebook (iGPU Intel HD4400), Vulkan não é suportado, então parece que o Minecraft vai quebrar
Antes, uma das vantagens era rodar em praticamente qualquer hardware, então é uma pena
Fico me perguntando por que não moveram os comentários para a fonte (thread relacionada)
É interessante ver a Microsoft mais próxima dos padrões da Khronos do que a Apple
Ela adotou SPIR-V como formato de saída e entrada do compilador de shaders do DirectX, aumentando a interoperabilidade com Vulkan
A Apple tinha muita insatisfação com a forma como o OpenCL foi tratado, e Sony e Nintendo quase não têm interesse na Khronos
Na prática, as APIs da Khronos têm problemas de espaguete de extensões, então a portabilidade completa deixa a desejar
O VulkanMod traz um grande ganho de desempenho, mas não é compatível com a maioria dos mods
Se no futuro der para usar Vulkan em modpacks completos, vai ser realmente empolgante
Seria ótimo se o Vibrant Visuals chegasse logo também ao Java Edition
É uma pena que, para usar shaders, quase sempre seja necessário recorrer a mods
Dá para instalar com drag-and-drop de um arquivo .zip, sem loaders complexos nem riscos de segurança
É menos flexível que Aperture, Iris e Optifine, mas oferece recursos bem parecidos
Fico curioso se shaders Vulkan também poderão ser incluídos em resource packs. Talvez isso seja limitado por haver mais risco de quebrar funcionalidades do jogo
Eu não sabia que existiam bindings de Vulkan para Java. Imagino que usem JNI
Também me surpreende que ainda estivessem usando OpenGL. Não acompanho o estado atual do Minecraft, mas também foi a primeira vez que descobri que existe uma versão desktop não-Java
O gerenciamento de memória fica muito mais limpo, e fazer bindings com funções externas (como Vulkan) fica muito mais fácil
Acho que é um dos recursos mais subestimados do Java recente
Fico me perguntando por que mantêm duas versões do mesmo jogo
O Bedrock quase alcançou a paridade de recursos, mas falhou como substituto completo
O Bedrock tem melhor desempenho e portabilidade, mas em consoles modding é inviável de qualquer forma
90% do conteúdo no YouTube é baseado em Java, então a Microsoft está focada em atingir equivalência de recursos
Do ponto de vista da Microsoft, manter as duas versões para maximizar a receita faz sentido
Espero que tenham resolvido bem o problema de travadas por compilação de shaders no Vulkan
Isso porque ele não usa um sistema complexo de materiais, e sim um renderizador de voxels relativamente simples
O problema aparece quando a engine gera muitas combinações de shaders ou quando algum estado específico da GPU (por exemplo, blending) provoca recompilação de shader
No Vulkan moderno, a maior parte dos estados pode ser tratada como estado dinâmico (dynamic state), o que reduz esse problema
Ainda assim, alguns estados, como blending, podem continuar provocando recompilação
Ou seja, se os desenvolvedores evitarem depender desses estados dinâmicos, é fácil prevenir essas travadas
Hoje em dia, muitos estúdios grandes acabam relaxando na otimização técnica
O Minecraft foi inicialmente desenvolvido em Java, mas depois de ser vendido para a Microsoft, acabou sendo feito mais uma vez em C++. Reimplementar um jogo inteiro mudando a linguagem de desenvolvimento não deve ter sido uma tarefa simples; é curioso como isso acabou acontecendo.
Parece que fizeram a edição Bedrock com foco em otimização para mobile...
Eu achava que iam abandonar o Java, mas no fim parece que resolveram atualizar as duas.