Suporte ao OpenGL 4.6 compatível no M1

Suporte ao OpenGL 4.6 e OpenGL® ES 3.2

• O M1 por muito tempo suportou apenas OpenGL 4.1, mas agora oferece suporte completo a OpenGL® 4.6 e OpenGL® ES 3.2.
• Basta instalar o Fedora para os drivers mais recentes das séries M1/M2.
• Se já estiver instalado, é possível atualizar simplesmente com o comando dnf upgrade --refresh.
• Diferentemente dos drivers 4.1 não padronizados de fornecedores existentes, esses drivers Linux de código aberto são certificados de acordo com versões modernas do OpenGL, prometendo ampla compatibilidade com cargas de trabalho OpenGL modernas como Blender, Ryujinx e Citra.

Certificação de drivers e suporte a padrões

• Drivers 4.6/3.2 certificados precisam passar por mais de 100.000 testes para garantir a correção.
• A lista de drivers oficialmente certificados agora inclui OpenGL 4.6 e ES 3.2.
• Os fornecedores ainda não oferecem suporte a padrões gráficos modernos como o OpenGL moderno, mas esta empresa oferece.
• A empresa expressa publicamente seu apreço por padrões abertos interoperáveis e quer dar a usuários e desenvolvedores a liberdade de executar aplicações onde quiserem, sem ports especiais.

Novidades do OpenGL 4.6

• O OpenGL 4.6 adiciona dezenas de recursos obrigatórios em comparação com o 4.1:
  • Robustness (robustez)
  • SPIR-V
  • Clip control
  • Cull distance
  • Compute shaders
  • Transform feedback aprimorado

Problemas de compatibilidade do M1 com padrões gráficos

• O M1 não se adapta bem a padrões gráficos mais novos que o OpenGL ES 3.1.
• O Vulkan torna alguns recursos opcionais, mas faltam recursos necessários nas camadas para DirectX e OpenGL.
• No M1, não havia solução existente que fosse além do conjunto de recursos do OpenGL 4.1.

Como superar a barreira do 4.1

• Foi necessária uma nova abordagem para implementar recursos novos sem suporte de hardware.
• Geometry shaders, tessellation e transform feedback são substituídos por compute shaders.
• Cull distance é substituído por valores interpolados transformados.
• Clip control é substituído por um epílogo de vertex shader.

Desafios da robustez

• Tradicionalmente, GPUs priorizam desempenho bruto em vez de segurança.
• Para aplicações como navegadores web, esse trade-off não é desejável.
• Recursos de robustez permitem reduzir a superfície de ataque com um pequeno custo de desempenho, possibilitando que a aplicação escolha um comportamento definido quando ocorrer acesso fora dos limites do buffer no shader.

Robustez de buffer

• Outras APIs têm definições diferentes sobre o que um carregamento fora dos limites do buffer retorna quando a robustez está ativada.
• O OpenGL faz com que carregamentos fora dos limites retornem o último elemento do buffer.
• Operações adicionais para robustez são movidas para o preâmbulo do shader, sem custo para o shader principal.

Robustez de imagem

• A robustez de imagem exige que carregamentos de imagem fora dos limites retornem 0.
• Há um único teste que falha com carregamento de imagem mipmap no GPU M1.
• Entre as soluções alternativas para robustez estão não carregar em níveis inválidos ou carregar de forma especulativa e depois usar operações de comparação e seleção.

Opinião do GN⁺

• Este artigo trata de um avanço importante no suporte ao padrão OpenGL moderno em dispositivos M1. Isso deve trazer compatibilidade mais ampla e melhor desempenho para usuários e desenvolvedores Linux.
• Os novos recursos do OpenGL 4.6 podem melhorar significativamente o desempenho e a robustez de aplicações gráficas, o que é especialmente importante em desenvolvimento de jogos e computação de alto desempenho.
• Este artigo é um bom exemplo de como drivers de código aberto podem oferecer melhor conformidade com padrões e compatibilidade do que soluções comerciais.

[GN⁺]

Comentários do Hacker News

• Alyssa Rosenzweig é uma pessoa que contribui continuamente para a comunidade, e ao ler os posts do blog dela é possível aprender coisas sobre o interior do hardware gráfico moderno que você não conhecia. Esse tipo de esforço prova que habilidade importa mais do que palavras, e só de ler o blog já se acaba refletindo bastante. A mensagem importante está na segunda frase, não na última, e o leitor acaba entrando na toca do coelho e se divertindo no mundo da manipulação de bits.
• O chip M1 não se encaixa bem em padrões gráficos mais novos do que OpenGL ES 3.1, e embora o Vulkan permita usar alguns recursos de forma opcional, faltam funcionalidades necessárias para o layering de DirectX e OpenGL. No M1, não existe solução que vá além do conjunto de recursos do OpenGL 4.1. Há curiosidade sobre o impacto disso no desempenho, especialmente em comparação com o Metal no macOS.
• Acho engraçado que, em programação gráfica, chamar de "robustez" a mudança de uma abordagem fora dos limites de trap para retorno de dados aleatórios.
• Em algum momento a Apple vai descontinuar o OpenGL 3.3 core, e por causa disso todo mundo talvez também o abandone. Em geral se diz que OpenGL é mais fácil de usar do que Vulkan, mas se ele ficar complexo demais, pode virar uma barreira para desenvolvedores menos experientes aproveitarem a GPU, o que pode desanimar alguns desenvolvedores indie de jogos. Usar Unity e Unreal é comum, mas fazer um jogo do zero acaba sendo visto como algo estranho. O estado atual do desenvolvimento open source de jogos às vezes parece bastante desesperador, e a chegada das APIs gráficas de próxima geração torna a situação ainda mais difícil.
• Isto é sobre o Fedora para o chip M1, e seria surpreendente implementar isso no macOS. Há curiosidade sobre que tipo de trabalho seria necessário para alcançar isso.
• Fico me perguntando por que não mirar primeiro em Vulkan. Hoje em dia, Vulkan parece ser um alvo mais importante, e já existem implementações de OpenGL.
• Como quebrar a barreira do 4.1? Para implementar novos recursos sem suporte de hardware, é preciso encontrar novos métodos. Geometry shaders, tessellation e transform feedback são implementados com compute shaders, cull distances com valores interpolados transformados, e clip control com o epílogo do vertex shader. Há curiosidade sobre quanto disso está sendo feito no código da GPU M1 e o quanto a implementação de recursos por meio de outros recursos pode ser reaproveitada.
• Mais uma recomendação, mais um artigo que eu gostaria de entender melhor no contexto, com mais conhecimento e paciência. Mesmo assim, os textos da Alyssa são divertidos de ler.
• É insano que a única razão de OpenGL ter sido usado em jogos 3D tenha sido o fato de John Carmack ter insistido nisso para Quake II nos anos 90.