Suporte ao Vulkan 1.3 no M1 em apenas um mês

• O Honeykrisp ainda não foi lançado para usuários finais; por enquanto, apenas o source code para desenvolvedores foi disponibilizado
• O Honeykrisp para M1 é a primeira implementação de conformant Vulkan em hardware Apple e implementa toda a especificação do Vulkan 1.3 sem portability waiver
• O Honeykrisp não parte do trabalho anterior de Vulkan no M1; ele foi baseado no driver NVK de código aberto para GPUs NVIDIA, começando pela adição de código para M1 e remoção das partes relacionadas à NVIDIA
• O resultado final da suíte de testes de conformidade do Vulkan 1.3 foi registrado como Pass 686930, Fail 0
• Todo o estado é tratado como estado dinâmico, e foi adicionado código para construir, compilar e armazenar em cache prolog e epilog, avançando na direção de full dynamic state e EXT_shader_object
• EXT_image_drm_format_modifier foi implementado para viabilizar zero-copy rendering
• Para compatibilidade com Direct3D, há suporte a EXT_custom_border_color, exigido por DXVK e vkd3d-proton, e a correção da border colour é emulada por meio da injeção de código no shader
• A emulação de custom border colour foi descrita como “simple, correct, and slow”, com planos de melhorar a velocidade depois com truques no driver
• O próximo trabalho é implementar os itens exigidos por DXVK e vkd3d-proton para a camada de Direct3D; um exemplo citado é transform feedback

[GN⁺]

Opiniões no Hacker News

• Um trabalho realmente impressionante, que mostra bem o valor de componentes abertos, compartilhados e aprimorados iterativamente
  Fico curioso para saber quanto tempo levará até o Proton ser portado, mas, mesmo que a implementação do Vulkan seja ótima, acho que muitos jogos terão desempenho ruim por causa das diferenças na arquitetura da GPU, da sobrecarga de tradução para ARM e do custo do próprio Proton
  Ainda assim, sou otimista de que, se SoCs como o Snapdragon se tornarem mais comuns em desktops, mais jogos passarão a mirar memória unificada e ARM no futuro

  • Seria bem irônico se a experiência de jogar no Asahi ficasse mais fácil e simples do que no macOS
    Isso mostra o tamanho do erro que foi a Apple ignorar o Vulkan nos últimos 10 anos, mas acho que ela nunca vai admitir antes que seja tarde demais
  • Um bom número de jogos que não precisam do dxvk roda a 60 FPS ou mais. Veja https://vt.social/@lina/112524118075585601
    Alyssa também vem trabalhando recentemente em melhorias de desempenho no FEX

• Fico me perguntando se esse trabalho de adicionar Vulkan ao Linux e traduzir DirectX no Asahi Linux vai afetar o sonho da Apple de atrair jogos AAA para o Apple Silicon
  A Apple deve querer que os estúdios AAA portem os jogos para Metal para que rodem no iPhone, iPad, Mac e Vision Pro com uma única base de código
  Talvez gamers de Mac acabem instalando o Asahi Linux para jogar títulos AAA de PC

  • O sonho da Apple não é que jogos AAA cheguem ao Apple Silicon, mas que cheguem à Apple App Store. Uma camada como o Proton pode ser feita como o GPTK
    O que ela realmente quer é ter jogos AAA na App Store, não na Steam ou na Epic Games Store; por isso acho que o GPTK é meio capado, e a licença também impede a Valve de integrá-lo diretamente à Steam
  • O Asahi Linux pode se tornar o novo Boot Camp para usuários de Mac que faziam dual boot para jogar
    Testei Diablo II Resurrected com Whiskey no M1, e foi bem impressionante ver um jogo nativo de Windows rodando tão diretamente. Hoje, o único obstáculo é uma atualização idiota do launcher da Blizzard que causa crash e impede o jogo de abrir
    Embora seja um jogo antigo em DX9, EverQuest II também rodou muito bem em 1440p em um Mac mini M1, e o Asahi Linux pode ajudar também com títulos antigos de 32 bits como Guild Wars
  • Se a Apple realmente quisesse isso, bastaria implementar o Vulkan
  • A Apple já lançou o Game Porting Toolkit

• Se você não conhece bem o Vulkan 1.3, mas tem interesse em trabalhar com APIs gráficas de baixo nível, vale muito a pena dar uma olhada. É um nível completamente diferente do Vulkan 1.0 e muda o jogo
  Depois de superar a barreira inicial, fica prazeroso trabalhar com ele, e a remoção de todo o estado dinâmico e da configuração prévia de render passes o torna muito mais fácil de lidar. Ficou até mais fácil que o OpenGL que usei por 20 anos, e programação gráfica voltou a ser divertida
  Com drivers modernos, dá para usar a maior parte dos recursos em praticamente qualquer plataforma desktop com uma GPU dos últimos 10 anos, aproximadamente
  Infelizmente, não existe um framework com “padrões sensatos” para começar imediatamente, mas há muitas bibliotecas auxiliares úteis para várias linguagens

  • Mexo um pouco com OpenGL há 20 anos e, embora não seja programador profissional de jogos, faço conteúdo 3D no tempo livre
    Ainda não tive tempo de migrar para Vulkan, mas parece que, no fim, basta superar a barreira de inicialização e configuração. Depois disso, acho que não vou querer voltar para OpenGL
    Este artigo me deu um pequeno empurrão para realmente tentar
  • Existe algum tutorial ou documentação para começar especificamente com Vulkan 1.3? Da última vez que procurei, só encontrei materiais misturando várias combinações do jeito antigo e do jeito novo
    Talvez não seja tão diferente assim, já que o OpenGL também era assim, mas dá a impressão de que a Khronos conseguiu fazer isso de novo

• Acabei de atualizar por causa do suporte a ES 3.2 e já estou impressionado. Meu M1 parece ter sido feito para o Asahi
  Sinceramente, é bem provável que o macOS só tenha sido iniciado uma vez, durante a instalação ou por acidente. É ótimo ter atualizações detalhadas assim
  Fico imaginando se algum navegador oferece suporte a renderização sem cópia, ou se ainda há várias camadas de compositor no meio. Também lembro que o feedback de transformação do WebGL2 ficava bloqueado por causar leitura de volta

  • Dá para remover completamente o macOS? Isso me fez considerar um Mac mini para viagens

• Sempre pensei que, se algo crashava, com certeza nunca seria bug do compilador, mas em 16 de abril foi mesmo um bug do compilador
  Posso dizer com segurança que nunca passei por isso na minha carreira, mas talvez seja menos raro quanto mais baixo for o nível de abstração

  • Não pode ser bug do compilador, e com certeza também não pode ser bug da CPU
    A menos que você seja desenvolvedor de kernel de baixo nível; nesse caso, ambos podem ser verdade
    Brincadeiras à parte, na prática quase sempre não é isso, mas definitivamente acontece
  • Pelo menos a parte do alocador de registradores não foi escrita por você mesmo?
    Se for um compilador em desenvolvimento, que é seu próprio trabalho em teste, o ditado “não pode ser bug do compilador” não se aplica muito bem

• Há uma estrutura peculiar no shader: if (condition) { while (true) { } }
condition é sempre falsa, mas o compilador não sabe disso
  Fico curioso para saber qual é o propósito dessa estrutura, além de ser um veneno para atormentar autores de compiladores de shaders que seguem o padrão

  • O ponto central do teste não é justamente jogar uma entrada venenosa para os autores de compiladores, para garantir que eles não quebrem seja qual for o shader que apareça?
    Mais do que esse código em si ser útil na prática, se uma parte de um shader puder ser simplificada funcionalmente para esse formato em certas situações, o compilador precisa lidar corretamente com isso
  • O objetivo dessa estrutura pode ser informar ao compilador que a condição é sempre falsa, fazendo o otimizador realizar mais otimizações
    Se o conceito não for familiar, veja esses recursos em C++, LLVM e Rust:
    https://en.cppreference.com/w/cpp/utility/unreachable
    https://en.cppreference.com/w/cpp/language/attributes/assume
    https://en.cppreference.com/w/cpp/memory/assume_aligned
    https://llvm.org/docs/LangRef.html#unreachable-instruction
    https://llvm.org/docs/LangRef.html#llvm-assume-intrinsic
    https://doc.rust-lang.org/std/hint/fn.unreachable_unchecked....
    https://doc.rust-lang.org/std/hint/fn.assert_unchecked.html
    Um loop infinito é, na prática, uma instrução inalcançável, e uma instrução inalcançável depois de um desvio se torna, na prática, uma instrução assume
  • É assim que um shader dá “panic”?
  • Também pode ser um caso-limite de algum tipo de geração de código

• Fico curioso se dá para usar isso dentro de uma VM. Desenvolvo no macOS e, no geral, estou satisfeito, mas rodo uma imagem Ubuntu no VMware para testes
  Como estou criando um app de gráficos 3D, não sei muito bem até que ponto vai o passthrough do VMware. Fico curioso se a GPU Apple Silicon é virtualizada na VM e se rodar essa distribuição poderia melhorar o desempenho gráfico

  • Precisa instalar nativamente. Se você quer boa performance 3D em uma VM Windows/Linux/macOS sobre macOS, o Parallels é bem melhor que o VMware

• Alguém pode explicar qual é a relação disso com o MoltenVK? Por ser um driver nativo, isso elimina a necessidade do MoltenVK?

  • MoltenVK é uma implementação de Vulkan baseada em Metal que permite executar aplicações Vulkan no macOS
    Asahi Linux é uma distribuição em desenvolvimento que tenta tornar o Linux compatível com processadores Apple série M, e este texto trata de fazer o Vulkan com aceleração de GPU funcionar no Asahi
  • Isto é sobre usar Vulkan no Asahi Linux em hardware Mac M1. O MoltenVK oferece Vulkan sobre Metal no macOS
  • Isto não é sobre macOS, e sim sobre Vulkan no Linux
  • MoltenVK traduz Metal para Vulkan. Metal é a principal API gráfica do OS X e do iOS, e isto é uma implementação nativa de Vulkan para Linux
    O texto também diz isso. Como isto não pode ser executado diretamente no OS X, não elimina a necessidade do MoltenVK