- O driver gráfico de kernel para GPUs Apple M1/M2, além de ter como característica ser baseado em Rust, ampliou o suporte a padrões ao alcançar conformidade com OpenGL 4.6 e Vulkan 1.3
- A tesselation, elemento central do OpenGL 4.0, é difícil de implementar de forma compatível com o padrão usando apenas os recursos de hardware da GPU Apple, então a solução foi portar o tessellator de referência da Microsoft para OpenCL C e executá-lo na GPU
- Em uma demo Vulkan no Mac M2, a tesselation baseada em OpenCL registrou 265fps, muito acima de menos de 1fps de uma implementação apenas em software, mas ainda abaixo dos 820fps de um tessellator por hardware
- Rodar jogos AAA exige adaptar um ambiente de DirectX, Windows, x86 e páginas de 4KB ao Apple Silicon baseado em Linux, Arm64 e páginas de 16KB, usando várias camadas de conversão e uma configuração com máquina virtual
- Jogos como Portal, The Witcher 3 e Cyberpunk 2077 realmente rodaram, mas exigências de memória e o escopo do suporte a ray tracing ainda seguem como limitações importantes
Driver de GPU Apple chega ao OpenGL 4.6
- O driver gráfico de kernel para GPUs Apple M1/M2 foi escrito em Rust e alcançou conformidade com vários padrões gráficos
- Alyssa Rosenzweig atualizou o estado do driver e os jogos suportados na X.Org Developers Conference 2024
- O material da apresentação foi publicado como vídeo no YouTube e slides
- Na XDC do ano anterior, o driver havia alcançado conformidade com OpenGL ES 3.1 e, depois disso, chegou também à conformidade com OpenGL 4.6
- A tesselation necessária para o OpenGL 4.0 é uma técnica para aumentar ou reduzir dinamicamente o nível de detalhe de uma cena
Limitações do tessellator de hardware da GPU Apple
- A GPU Apple tem um tessellator por hardware, mas faltam recursos necessários para uma implementação compatível com o padrão OpenGL, então o driver não pode usá-lo diretamente
- O hardware aparentemente não oferece suporte a point mode nem a isoline, e esses dois recursos podem ser emulados
- O problema maior é transform feedback e geometry shader
- O hardware não oferece suporte a nenhum dos dois
- O driver os emula com compute shader
- Como diferenças no algoritmo de tesselation entre o tessellator por hardware e a emulação podem causar falha de invariance, essa combinação deve ser evitada
- A Apple oferece suporte a OpenGL 4.1, mas sem conformidade, e substitui em software os recursos que o hardware não suporta
- Rosenzweig deixou claro que não está implementando Metal, então não seguirá por esse caminho
O tessellator de referência portado para OpenCL C
- O driver aproveita o tessellator de referência que a Microsoft publicou há mais de 10 anos
- Originalmente, era um código para mostrar o comportamento que fabricantes de hardware precisariam implementar ao adotar tesselation
- São cerca de 2.000 linhas de código em C++ que fazem a tesselation de um único patch
- Como não é possível executar diretamente 2.000 linhas de C++ em um driver de GPU, esse código foi portado para OpenCL C
- OpenCL C é muito parecido com C comum de CPU, mas com limitações e extensões voltadas a GPU
- O objetivo não era entender completamente o código, e sim portá-lo sem quebrar o comportamento
- O tessellator de CPU processa apenas um patch por vez, mas uma cena pode ter 10.000 patches
- A enorme capacidade de paralelismo da GPU é usada para que várias threads façam a tesselation
- Durante o processamento paralelo, a alocação de buffers de saída é gerenciada com instruções atômicas da GPU
- A saída do tessellator precisa ser desenhada como comandos de draw no formato de packed data structure exigido pela GPU
- Normalmente, no código do driver em C, isso é tratado por funções geradas pela GenXML tool
- Como o tessellator está em forma de código C graças ao OpenCL, essas funções geradas podem ser incluídas no código executado na GPU
Desempenho da tesselation
- A tesselation baseada em OpenCL foi usada para executar terrain tessellation em uma demo Vulkan em um Mac M2
- A comparação de desempenho é a seguinte
- terrain tessellation apenas em software: menos de 1fps
- tesselation baseada em OpenCL: 265fps
- resultado medido conectando o tessellator por hardware: 820fps
- Rosenzweig avaliou o desempenho da abordagem com OpenCL como “bom o suficiente” e acredita que, em jogos reais, a chance de isso virar gargalo é baixa
- Ainda há espaço para melhorar o desempenho do driver
Vulkan 1.3 e Honeykrisp
- O driver Honeykrisp para GPUs M1/M2 alcançou conformidade com Vulkan 1.3
- O ponto de partida foi uma cópia do driver Vulkan NVK para GPUs NVIDIA, combinada com o driver OpenGL 4.6
- Em cerca de um mês, ele já começou a passar na suíte de testes de conformidade
- Isso aconteceu cerca de 6 meses antes da apresentação
- Depois, os seguintes recursos foram adicionados
- geometry shader
- tessellation shader
- transform feedback
- shader object
- Atualmente, o driver oferece suporte a todos os recursos necessários para várias versões de DirectX
Camadas de conversão para rodar jogos AAA
- Para rodar jogos AAA no ambiente Apple Silicon, é preciso lidar ao mesmo tempo com várias diferenças de plataforma
- Ambiente alvo dos jogos: DirectX, Windows, CPU x86, páginas de 4KB
- Hardware real de destino: Apple Silicon baseado em Linux, Arm64 e páginas de 16KB
- A conversão de DirectX para Vulkan e a execução de Windows em Linux ficam por conta de DXVK e Wine, respectivamente
- Para converter de x86 para Arm64, já existem opções como FEX-Emu e Box64
- O maior obstáculo é a diferença no tamanho de página
- O FEX-Emu exige páginas de 4KB
- O Box64 tem um hack para usar páginas de 16KB, mas isso não funciona com Wine, então não ajuda neste caso
- O macOS pode usar páginas de 4KB para emulação x86, mas isso exige um suporte de kernel muito invasivo
- O Asahi Linux já carrega cerca de 1.000 patches a caminho do kernel principal, então reescrever o gerenciador de memória do Linux não é uma abordagem razoável
Configuração de VM com kernel convidado de 4KB
- O Linux não oferece suporte a tamanhos de página heterogêneos entre processos diferentes, mas isso é possível entre kernels diferentes, e é resolvido com virtualização
- Um kernel convidado KVM pode ter um tamanho de página diferente do kernel host
- Foi usada uma estrutura que coloca FEX-Emu, Wine, DXVK, Honeykrisp, Steam e o jogo inteiro dentro de uma máquina virtual que roda um kernel convidado de 4KB
- Esperava-se que o overhead de CPU fosse baixo graças à virtualização por hardware, e o custo real ficou mais do lado dos periféricos
- O Honeykrisp roda no convidado, não no kernel host, via virtgpu native contexts
- A criação do command buffer final da GPU acontece no convidado
- Em vez de cada chamada Vulkan atravessar a fronteira da máquina virtual, o command buffer pronto é enviado ao host
- O renderer VirGL no host então o envia para a GPU
- Rosenzweig disse que essa abordagem não atinge 100% de velocidade nativa, mas passa com folga de 90%
- Como os overheads de CPU e GPU rodam em paralelo, seus custos não se somam diretamente
Jogos que realmente rodaram e estado de disponibilização
- Essa configuração realmente rodou vários jogos
- Portal
- Portal 2
- Castle Crashers
- The Witcher 3
- Fallout 4
- Control
- Ghostrunner
- Cyberpunk 2077
- Os componentes relacionados foram divulgados no próprio dia da apresentação, 10 de outubro
- Usuários do Fedora Asahi Remix podem atualizar imediatamente para receber esses componentes
- Durante a apresentação, iniciar o Steam levou tempo por causa da máquina virtual e da emulação x86; depois disso, Control rodou a 45fps em um sistema M1 MAX
Limitações de memória e ray tracing
- Alguns jogos conseguem rodar até em Macs com 8GB de RAM
- Rosenzweig jogou Castle Crashers em um sistema de 8GB durante a conferência
- Portal também funciona em um sistema de 8GB
- Títulos mais avançados provavelmente só funcionarão em sistemas com 16GB ou mais
- Rosenzweig espera que, com o tempo, os recursos necessários diminuam
- O suporte a ray tracing não é uma prioridade alta
- Control pode usar esse recurso
- O hardware da Apple só oferece suporte a ray tracing a partir do M3
- O driver atual é para GPUs M1 e M2
- Rosenzweig pretende começar em breve o trabalho para o M3
1 comentários
Opiniões no Hacker News
A dedicação em levar até o fim o suporte ao M1/M2 é realmente admirável
Há projetos demais que são abandonados assim que aparece um novo brinquedo reluzente de ray tracing; esse tipo de trabalho é sofrido por causa de hardware pouco documentado, mas a recompensa é grande quando funciona
Também comprei meu M1 por causa deste projeto e do trabalho da Alyssa em OpenGL+ES, e só inicializo o Asahi Linux
Esses dispositivos são feitos para durar, e o suporte de longo prazo tanto da própria Apple quanto da comunidade Linux é digno de elogios
Por ser open source, é bem possível que a Apple também esteja observando, e o texto também abordava o trabalho de contornar recursos ausentes nos chips
Programo há mais de 20 anos, mas os momentos mais felizes e mais deprimentes da minha carreira vieram todos de um projeto de hardware do qual participei por apenas 4 meses
A abordagem da Alyssa de rodar tudo em uma máquina virtual para resolver a diferença entre tamanhos de página de 4 KB e 16 KB parece um hack inteligente, mas também um possível gargalo de desempenho
Fico curioso sobre o que esse tipo de workaround significa no longo prazo
Será que não chegamos ao ponto em que a complexidade de preencher as lacunas de um hardware proprietário projetado para um ecossistema fechado começa a superar os benefícios?
Ver Control rodando a 45 fps em um M1 MAX com drivers open source é animador, mas fico em dúvida se a comunidade deve continuar investindo muitos recursos para abrir mais sistemas fechados, ou se deveria pressionar por padrões de hardware mais abertos
A Apple cria obstáculos desnecessários para desenvolvedores com limitações de GPU que dificultam recursos padrão como tessellation shaders e com tamanhos de página não padronizados; esse tipo de ecossistema fechado não só dificulta a vida de contribuidores open source como também sufoca inovações que beneficiariam todos os usuários
É óbvio que isso sustenta um modelo de negócios fechado, e na prática funciona muito bem para a Apple
Ela faz hardware excelente e, embora o software recente esteja um tanto instável, o usuário comum geralmente tem uma boa experiência com a combinação de hardware e software
Portanto, o fato de a Apple projetar hardware assim não significa que ela esteja colocando “obstáculos desnecessários” para desenvolvedores; ela simplesmente está focada em projetar hardware de acordo com suas próprias necessidades
Além disso, se o hardware não fosse excelente, não haveria tanto interesse em usá-lo de formas que a Apple não pretendia
Há uma diferença bem grande entre ignorar padrões e reinventar uma roda melhor, e se desviar intencionalmente dos padrões para impedir compatibilidade
O ponto central é se eles simplesmente não gastam recursos para manter o comportamento padrão, ou se gastam recursos ativamente para se afastar do padrão; se for o primeiro caso, pessoalmente não acho que seja algo a culpar
Dentro desse ecossistema, o que a Apple provavelmente mais se importa é compatibilidade com apps nativos e uma experiência de inferência de IA em nível semelhante, e ambas às vezes parecem ser resolvidas por esforço conjunto
Fora isso, ela prefere travar o máximo possível, e a comunidade, infelizmente, tende a ser mais atraída pelo apelo geral do que por boas iniciativas abertas
Dá para fazer os dois
No começo eu ia dizer que a Alyssa deveria trabalhar na Valve e ajudar a fazer o Steam rodar no Linux em Macs, mas parece que ela já faz isso [1]
[1] https://en.wikipedia.org/wiki/Alyssa_Rosenzweig#Career
Isso levanta uma pergunta bem interessante sobre o que a Valve está planejando aqui
Embora seja difícil, rodar Steam/Proton no Mac faz muito sentido para a Valve, e se as pessoas passarem a inicializar Linux no Mac para jogar, a Apple provavelmente vai ficar bem incomodada
O trabalho da Alyssa R e da Asahi Lina é excelente
Mas, se você não está familiarizado com código de drivers, a maior parte disso é realmente difícil de entender, e o lado de hardware tem tantas peculiaridades que seria ótimo se fosse possível escrever esse tipo de código com muito mais facilidade
Também achei bem divertida a brincadeira à moda antiga do figurino de bruxa
Fiquei curioso para saber se existe algum hardware conhecido capaz de fazer isso
Pesquisei, mas foi difícil encontrar o que eu queria em meio ao spam de blogs sobre PowerPoint, e a IA do Google também não ajudou
Fico imaginando se mais alguém se surpreendeu com a quantidade de coisas ausentes no hardware e com quantas partes são emuladas
Dá para dizer que, na prática, tudo é emulação
Um dos motivos pelos quais fabricantes de GPU não querem abrir o código dos drivers é que boa parte do molho secreto acontece no software do driver sobre essa arquitetura de computação massivamente paralela
Geometry shaders são amplamente vistos como um erro que nem deveria ter sido padronizado, e o Metal nunca deu suporte a eles, então só apareceriam em código OpenGL antigo no macOS; por isso, é difícil culpar a Apple por não oferecer suporte a isso em hardware
https://x.com/pointinpolygon/status/1270695113967181827
Alyssa é incrível
Lembro do primeiro texto dela sobre trabalho com GPU; depois, quando descobri que ela tinha só 17 anos, senti como se minha cabeça fosse explodir
O simples fato de alguém ter conseguido fazer aquilo já é impressionante; uma adolescente ter feito é realmente chocante
Se trazer OpenGL e Vulkan modernos para o Apple Silicon é impossível de qualquer forma sem uma camada de emulação, teoricamente seria possível criar uma API Metal nativa para Linux?
Ou o Metal está profundamente demais integrado ao SDK do macOS?
O MoltenVK também está tentando resolver o mesmo problema de que Alyssa falou na apresentação [1, o último comentário da issue é da Alyssa]
[1] https://github.com/KhronosGroup/MoltenVK/issues/1524
Essa foi, na prática, a conclusão da apresentação de Alyssa Rosenzweig
Como a Apple conhece a documentação interna, ela está na melhor posição para criar uma implementação de baixo nível melhor
Hoje, o principal obstáculo é a postura teimosa de que portar para Metal é o único caminho oficialmente suportado
Se a Valve conseguir tirar da cartola algum método mágico para rodar jogos AAA no Mac sem suporte da Apple, isso criaria uma dinâmica interessante e poderia levar a Apple a repensar sua abordagem, caso não queira ficar encurralada em sua própria plataforma
Já existem implementações de DirectX para Linux, e o Proton funciona desse jeito
A questão é se essa API seria feita como uma camada sobre o Vulkan, se seria tratada inteiramente do lado do cliente como o MoltenVK ou o dxvk, ou se seria integrada mais profundamente ao Mesa
Para começar, a primeira opção certamente parece mais fácil
Fui condicionado a esperar que, ao ver um texto com esse tipo de título, o conteúdo seria algo como “o suporte será encerrado e a equipe será acqui-hired”
Alyssa Rosenzweig merece receber o Turing Award
Sempre fiquei curioso com esses links /SubscriberLink/
Será que é antiético compartilhá-los?
E-mails pessoais, mensagens em listas de discussão de projetos e posts de blog são todos apropriados, e eles dizem que gostam que sejam compartilhados, desde que não sejam usados como meio de contornar tentativas de conquistar assinantes
Mas também pediu educadamente para não espalhar demais, já que precisam manter o site, os autores e os editores, e, pelo que entendo, essa receita vem apenas das assinaturas
A assinatura da LWN é bem acessível e apoia a melhor cobertura técnica aprofundada sobre Linux e temas relacionados
Não tenho relação com a LWN; sou apenas um assinante satisfeito, e considero que o conhecimento que obtive nos artigos da LWN também contribuiu em parte para meu sucesso profissional
Para as pessoas assinarem, primeiro precisam saber que a LWN existe
Veja o FAQ: https://lwn.net/op/FAQ.lwn#slinks
O paywall da LWN é peculiar, pois todo o conteúdo fica gratuito depois de uma semana
Os links de assinante existem para incentivar a assinatura por quem tiver condições
Posso estar errado, mas isso soa como se houvesse algum financiamento para liberar, artigo por artigo, conteúdo que antes era pago
Fico curioso se alguém sabe se é isso mesmo