Primeiro driver de GPU M1 com certificação de conformidade OpenGL ES

 (rosenzweig.io)
1 pontos por GN⁺ 2023-08-23 | 1 comentários | Compartilhar no WhatsApp
  • Foi disponibilizado um driver para Linux capaz de executar aplicações OpenGL ES 3.1 em GPUs das famílias M1 e M2 de acordo com o padrão
  • O driver livre e de código aberto do Asahi Linux, baseado em engenharia reversa, é a única implementação de OpenGL ES 3.1 em hardware gráfico M1 e M2 aprovada nos testes de conformidade da Khronos
  • A certificação envolve aprovação nos testes oficiais, envio à Khronos e um período de revisão de 30 dias, com registros para M1, M1 Pro/Max/Ultra, M2 e M2 Pro/Max
  • O OpenGL ES 3.1 atualiza o suporte experimental a OpenGL ES 3.0 e OpenGL 3.1 lançado em junho e adiciona compute shaders e operações atômicas de imagem
  • O M1 não tem instruções dedicadas para operações atômicas de imagem, então foi usado um desvio por cálculo de endereço; depois, uma instrução de interleaving de bits foi encontrada e reduziu 10 instruções para 1

Certificação de conformidade OpenGL ES 3.1 para M1 e M2

  • Foi disponibilizado um driver com certificação de conformidade OpenGL ES 3.1 para GPUs das famílias M1 e M2
    • Compatível com aplicações OpenGL ES 3.1
    • Pode ser usado com uma instalação Linux
  • Usuários atuais do Asahi Linux podem obter o driver mais recente com o comando de atualização da sua distribuição
    • Fedora: dnf upgrade
    • Arch: pacman -Syu
  • O driver gráfico livre e de código aberto, baseado em engenharia reversa, está disponível em asahi/mesa
  • Este driver é a única implementação com certificação de conformidade OpenGL ES 3.1 do mundo para hardware gráfico das famílias M1 e M2
    • Passou por dezenas de milhares de testes, comprovando sua correção
    • Recebeu reconhecimento do órgão responsável pelo padrão no setor

Processo da Khronos e famílias de chips registradas

  • Para obter a certificação de conformidade, a implementação precisa passar pela suíte oficial de testes de conformidade
    • A suíte de testes foi projetada para verificar todos os recursos da especificação
    • Os resultados são enviados ao organismo de padronização Khronos
    • Se não houver problemas durante o período de revisão de 30 dias, ela se torna uma implementação certificada
  • No site da Khronos, os seguintes drivers estão registrados como implementações certificadas
  • Este resultado não se limita ao OpenGL ES
    • É a primeira implementação com certificação de conformidade em qualquer padrão gráfico para o M1

A distância entre o driver do fabricante e as APIs padrão

  • O driver do fabricante para o M1 não obteve certificação de conformidade em nenhuma API gráfica padrão, incluindo Vulkan, OpenGL e OpenGL ES
  • Em ambientes M1 e M2 que não usam Linux, não há garantia de que aplicações baseadas em padrões funcionarão
  • No caso do Vulkan, o MoltenVK coloca parte do Vulkan em camadas sobre o driver proprietário
    • Esse driver proprietário não inclui recursos essenciais
    • Aplicações Vulkan válidas podem falhar
    • Isso se torna um obstáculo tanto para desenvolvedores quanto para usuários que não migraram seus computadores M1 e M2 para Linux
  • O desenvolvimento do driver do Asahi Linux tem como objetivo fazer com que software padrão rode no M1 sem hacks específicos nem portabilidade especial
    • Não se contenta com drivers proprietários, APIs proprietárias ou a recusa em implementar padrões
    • Enxerga a implementação de padrões abertos conforme a especificação como a direção desejável para o ecossistema

Principais recursos adicionados no OpenGL ES 3.1

  • O OpenGL ES 3.1 atualiza o suporte experimental a OpenGL ES 3.0 e OpenGL 3.1 disponibilizado em junho
  • O principal recurso adicional são os compute shaders
    • Eles são usados principalmente para acelerar computação geral dentro de aplicações gráficas
    • Jogos 3D podem executar simulações de física em compute shaders
    • Se os resultados da simulação forem usados diretamente na renderização, é possível reduzir pausas causadas pela sincronização entre a GPU e a simulação de física na CPU
    • Como resultado, o jogo pode rodar mais rápido

Por que operações atômicas de imagem são necessárias

  • Versões anteriores do OpenGL ES permitiam que aplicações lessem imagens para exibição na tela
  • O ES 3.1 permite que aplicações façam escritas em imagens, normalmente em compute shaders
    • Isso reduz a necessidade de adaptar algoritmos de processamento de imagem ao pipeline 3D de função fixa
  • A GPU é uma arquitetura massivamente paralela que executa milhares de threads ao mesmo tempo
    • Se duas threads escreverem no mesmo local, o resultado pode variar conforme a ordem de execução
    • Essa situação é uma condição de corrida
  • O acesso atômico à memória é a solução básica para lidar com condições de corrida
    • Hardware especial no subsistema de memória garante resultados consistentes para operações selecionadas, independentemente da ordem das threads
    • Hardware gráfico moderno oferece várias operações atômicas, como soma
  • A extensão do OpenGL ES OES_shader_image_atomic adiciona operações atômicas em pixels de imagem
    • Essa extensão é obrigatória no ES 3.2
    • Por exemplo, um compute shader pode incrementar atomicamente o valor do pixel (10, 20)

Como operações atômicas de imagem foram implementadas no M1

  • Outras GPUs oferecem instruções dedicadas para operações atômicas de imagem, o que simplifica a implementação no driver
  • O M1 não possui instruções de hardware dedicadas para operações atômicas de imagem
    • Ele possui operações atômicas não relacionadas a imagem
    • E também recursos de imagem não atômicos
  • Por isso, em vez de executar uma operação atômica diretamente no pixel, calcula-se o endereço de memória do pixel e então aplica-se uma operação atômica comum naquele endereço
  • Se a imagem estiver disposta linearmente na memória, o cálculo do endereço é simples
    • Multiplica-se a coordenada Y pelo stride, ou seja, os bytes por linha
    • Multiplica-se a coordenada X pelos bytes por pixel
    • Soma-se os dois valores para obter o deslocamento em bytes a partir do primeiro pixel
    • Soma-se esse deslocamento ao endereço do primeiro pixel para obter o endereço final
  • Na prática, as imagens normalmente não são organizadas de forma linear
    • Hardware gráfico moderno intercala coordenadas X e Y para melhorar a eficiência de cache
    • A disposição dos pixels na memória não segue linhas, mas uma curva parecida com uma espiral

Otimização de interleaving de bits e busca por uma instrução oculta

  • Intercalar X e Y mascarando e deslocando um bit por vez é ineficiente
  • Um conhecido algoritmo de manipulação de bits mistura grupos de bits para paralelizar o problema
    • Implementar esse algoritmo no código do shader melhorou o desempenho
  • Na prática, apenas os 7 bits menos significativos ou menos de cada coordenada são intercalados
    • Colocando X e Y nos 16 bits baixos e altos de um registrador de 32 bits, é possível processar ambos ao mesmo tempo com uma instrução de 32 bits
    • Isso reduz pela metade o número de instruções
    • Também aproveita a instrução combinada de shift-and-add da GPU
  • Combinando essas técnicas, foi possível realizar o interleaving com 10 instruções em assembly da GPU M1
  • Depois disso, foi investigada a possibilidade de uma instrução dedicada de interleaving de bits
    • A PowerVR possui a instrução de shuffle shfl
    • Como a GPU do M1 tem elementos herdados da PowerVR, foi considerada a possibilidade de existir uma instrução semelhante
    • Como o compilador proprietário não usava essa instrução ao compilar shaders de teste, era difícil fazer engenharia reversa apenas observando a saída da compilação

Confirmação da instrução de interleaving por hipótese e teste

  • Dougall Johnson estimou um candidato com base na codificação de instruções já conhecida
  • A instrução de reversão de bits tem um campo de 2 bits que especifica a operação, e o valor é 01
    • A instrução de contagem de bits ligados usa 10
    • A instrução de localizar o primeiro bit ligado usa 11
    • As instruções complexas de manipulação de bits já conhecidas usam esses três valores
  • O valor restante, 00, era um valor desconhecido ainda não observado
    • Se existisse uma instrução de interleaving, foi considerada a possibilidade de ela ser parecida com a instrução de reversão de bits, mas com opcode 00
  • As três instruções conhecidas usam apenas uma fonte de entrada, mas a instrução de interleaving precisaria de duas
    • As instruções da GPU M1 normalmente codificam as posições das fontes de maneira consistente
    • Em instruções aritméticas com duas fontes havia um espaço vazio onde a segunda fonte apareceria, e esse local foi assumido como a segunda fonte
  • A verificação foi feita modificando o compilador para trocar uma operação inteira de duas fontes, como multiplicação, pela codificação estimada da instrução de interleaving
    • Essa operação foi usada em um compute shader
    • O shader de teste verificou se a instrução desconhecida retornava o resultado de interleaving para cada entrada possível
    • Como a instrução recebe duas fontes de 16 bits, existem cerca de 4 bilhões de entradas
    • Com o novo suporte a compute no driver, a GPU M1 verificou todas as entradas em menos de 1 segundo
  • No fim, o assembly vetorizado de 10 instruções foi substituído por 1 única instrução de interleaving
    • Essa abordagem é rápida e também passou nos testes de conformidade

Leituras relacionadas

1 comentários

 
GN⁺ 2023-08-23
Opiniões no Hacker News

  • Fico curioso se o suporte a OpenGL/Vulkan vai melhorar, já que a Apple está colaborando com nVidia, Adobe, Autodesk, Microsoft e outras no OpenUSD, um formato para cenas de renderização/animação/CAD/3D
    Se o ponto central do OpenUSD é “um único formato de arquivo que renderiza de forma consistente em qualquer lugar”, há a possibilidade de a Apple usá-lo como meio para atrair mais empresas de software 3D para o macOS
    Daqui para frente, parecem existir dois caminhos: a Apple adotar os padrões OpenGL/Vulkan existentes, que ganham força nos pipelines de produção de filmes e jogos, ou, ao contrário, empurrar o Metal com mais força e levar o mundo para Metal + macOS
    Meu coração torce pela primeira opção, mas minha intuição diz que a Apple deve apostar tudo na segunda; e não só a Apple, como também nVidia, Autodesk, Adobe e Microsoft, costumam não gostar de padrões que não controlam

    • Eu acrescentaria a nuance de que “a Apple gosta de padrões abertos quando está em posição fraca”
      O iMac e o OS X inicial davam muito destaque a padrões como USB, JPEG, MPEG, mp3, PostScript, TCP/IP integrado e .rtf, e Jobs também enfatizava isso
      Depois, ao se recuperar da beira do abismo, ela voltou a começar a “agregar valor”; e o iPhone, no início, também era apresentado como um dispositivo HTML, em vez do Flash proprietário e péssimo ou do “HTML móvel” imaturo
      Ainda hoje, em áreas em que seu domínio de mercado é fraco, ela oferece suporte a padrões que não controla, como H.264 e Matter/Thread
    • A Apple dá suporte a vários padrões abertos, mas parece mais preciso dizer que ela “não quer depender de padrões que não controla”
      Como ela combina hardware e software de forma forte para criar a experiência de usuário pretendida, dá para entender a postura de tentar implementar padrões que sejam controláveis em alguma medida, para que essa experiência não fique à mercê de terceiros
      Mesmo padrões industriais cujo rumo ainda não está consolidado, como o USB-C, podem ter sua direção influenciada se a Apple se mover primeiro, então há casos em que ela os adota
    • OpenUSD é uma forma de empacotar e especificar os dados a serem renderizados; isso é independente de qual API o aplicativo usa para aceleração de renderização
      Adobe, Autodesk, Blender e a maioria dos outros já dão suporte a backends diferentes por sistema operacional, e no macOS isso inclui Metal
    • Não acho que a Apple vá voltar ao OpenGL
      OpenGL é antigo demais, manter bons drivers é quase um pesadelo, e até escrever código de aplicação com bom desempenho é difícil, então não sinto tanta falta assim
      Dito isso, eu gostaria que ela tivesse impulsionado o Vulkan em vez de criar o Metal; mas, fora do Linux, o Vulkan geralmente é quase um cidadão de segunda classe, embora ainda seja um cidadão de segunda classe bastante bom para mirar como alvo
      Do ponto de vista de suporte a jogos ou ao Steam, muitos jogos deixam o tratamento da API por conta da engine, e equipes que têm fôlego para lidar diretamente com a API provavelmente ficam bem com o MoltenVK, desde que não usem recursos muito de ponta
      Usei muito OpenGL a vida toda por causa de multiplataforma, mas era uma API realmente horrível por causa de estado global, funções que não deveriam ser usadas, armadilhas, headers de extensão gigantescos e depuração difícil; Vulkan é verboso, mas em muitos aspectos é até mais fácil
    • A situação Metal/Vulkan/OpenGL é lamentável, e não entendo bem as motivações da Apple
      Mas o Mac que uso hoje está conectado a vários periféricos e a um monitor grande apenas por portas USB-C, usando protocolos padrão
      De modo geral, a Apple parece preferir padrões abertos quando eles são bons o suficiente; na época em que o USB2 não conseguia fazer muitas das coisas que o Lightning fazia, ela criou o Lightning, mas quando o USB-C surgiu, aceitou-o rapidamente no Mac e no iPad, embora infelizmente esteja enrolando no iPhone

  • Asahi e Alyssa são gigantes da engenharia reversa, e o trabalho deles é inacreditável
    Acho bem provável que a Apple tenha tentado contratá-los, ou que já tenha tentado e sido recusada

    • Alyssa já tem contrato com a Valve
      Dá até para argumentar que a Valve tem motivos comerciais maiores do que a Apple para aproveitar essa competência
    • A Apple provavelmente já tentou, mas foi recusada por causa de NDA e cláusulas de não concorrência; ou então o RH não conseguiu avaliar corretamente o perfil deles
    • Emprego não é uma oferta tão boa assim
      Em geral, funcionários recebem pouco em comparação com o lucro que geram, e em TI isso é especialmente verdadeiro
      Para pessoas talentosas, é melhor criar uma pessoa jurídica e vender serviços por um preço justo, mas em alguns países grandes empresas fizeram lobby junto ao governo para bloquear esse caminho

  • O truque das operações atômicas foi muito satisfatório, e foi especialmente impressionante inferir a instrução de swizzle a partir da linhagem PowerVR
    Imagino que os engenheiros da Apple também aprendam com isso ou, no mínimo, valorizem essa engenhosidade
    Isso me lembra quando, no passado, a Accolade fez engenharia reversa do hardware de vídeo do Sega Genesis: os engenheiros usaram a documentação pública do VDP Texas Instruments TMS9918 como ponto de partida para inferir o VDP derivado do 9918 do Genesis (Mega Drive)

    • A Apple tem documentação interna dos próprios chips, então, embora provavelmente valorize muito o trabalho em si, não é uma situação em que eles criam uma caixa-preta e depois, ao escrever software, esquecem como ela foi projetada

  • Só para deixar claro: isso não é apenas o primeiro driver Linux com certificação de conformidade; o significado é maior
    Como a própria Apple não está em conformidade com OpenGL ES 3.1, este é literalmente o primeiro driver OpenGL ES 3.1 com certificação de conformidade para a série M em qualquer sistema operacional
    É por isso que aparece o pedido para doar à equipe
    https://asahilinux.org/support/

    • Gosto muito do trabalho que fazem, mas, certa vez, ao clicar em um link do asahilinux no Hacker News, apareceu um pop-up dizendo que leitores do Hacker News não eram bem-vindos no site, então não consegui ler o conteúdo
    • Fico curioso se isso pode ser usado no macOS
    • O link do GitHub ali leva ao marcan, que lidera o Asahi, mas eu gostaria principalmente de apoiar o desenvolvimento de drivers
      Se houver uma opção para isso, gostaria de saber onde; se não houver, depois usarei simplesmente aquele link

  • Hoje, ao depurar apps OpenGL para macOS, que já não são mais recomendados, esse problema fica muito evidente
    Isso acontece porque a camada de abstração não expõe o estado real do OpenGL de uma forma que o antigo depurador OpenGL da Apple consiga ler
    A menos que você tenha um Mac antigo com uma versão velha do macOS em que o OpenGL ainda não rodava internamente sobre Metal, na prática não dá para depurar OpenGL no macOS com o depurador padrão
    O depurador ou o app simplesmente trava

  • Isso parece ajudar principalmente jogos, e não tanto deep learning
    O ponto mais atraente do Mac M1 é a grande capacidade de memória; talvez não seja tão bom para treinamento, já que não dá para distribuir em várias placas, mas é bom como motor de inferência para modelos grandes como Stable Diffusion e LLaMA

    • Os padrões modernos de GPU de uso geral, multiplataforma, que o Apple Silicon teoricamente poderia usar ou implementar são dois: SYCL e Vulkan Compute
      SYCL é um framework de programação de alto nível, neutro em relação a fornecedores, do Khronos Group, mas o suporte em aplicações é limitado; espera-se que melhore gradualmente com o apoio da Intel
      Vulkan Compute contorna o problema usando compute shaders, mas não sei bem como está o suporte nas aplicações
      SYCL pode ser implementado sobre OpenCL e a extensão SPIR-V do OpenCL, mas, por causa do forte aprisionamento a fornecedores, esse caminho foi em grande parte abandonado fora da Intel e do Mesa; hoje, muitas vezes ele é implementado como backends para APIs de cada fornecedor de GPU, como ROCm, HIP e CUDA
      Aplicar a mesma abordagem ao Metal seria muito difícil; no Mesa há suporte experimental a OpenCL+SPIR-V para Intel e AMDGPU, o que em teoria poderia ser estendido ao Apple Silicon, mas atualmente o OpenCL do Apple Silicon não tem suporte nenhum e estava apenas no roadmap
    • Exato
      Para rodar deep learning, é preciso um backend como CUDA, ROCm, MPS
      Era relativamente fácil treinar um modelo PyTorch em um grande servidor CUDA e rodar inferência em um MacBook Air
    • A parte dos compute shaders é um bom avanço, mas ainda não fornece a interface que essas ferramentas de deep learning esperam
      Porém, eiln escreveu um driver para o Apple Neural Engine, permitindo usar hardware dedicado em vez da GPU, e ele deve ser integrado ao linux-asahi no futuro
    • TensorFlow Lite de fato oferece suporte a OpenGL ES

  • Dizer que Asahi Lina e duas pessoas derrotaram uma grande empresa com financiamento mínimo é uma formulação elegante, mas, na prática, foi menos uma vitória e mais algo com que a Apple não se importava
    A Apple nem entrou nessa corrida para começo de conversa

  • Gosto do eufemismo “duas pessoas, com financiamento mínimo, derrotaram uma grande empresa”
    Isso é claramente vergonhoso para a Apple, e a Apple não se importa com padrões nem conformidade; ela quer que as pessoas fiquem presas no seu próprio jardim murado
    Se eu não fosse desenvolvedor iOS, teria saído do ecossistema Apple há muito tempo
    Gosto do hardware e também gostava da marca que, como a Apple dos anos 80 e 90, defendia criatividade e foco no ser humano; mas a empresa de hoje parece podre de ganância por trás de vídeos de marketing politicamente corretos

    • Concordo totalmente, mas encontrar uma alternativa significativa é, na prática, quase impossível
      Na última atualização, procurei alternativas, mas sair da Apple significava aceitar concessões sem fim
      No lugar do iPhone, considerei um Pixel na esperança de ter Android puro e suporte longo, mas não paravam de aparecer relatos de problemas de bateria, e a qualidade do software, o ecossistema de apps e a estabilidade também eram obstáculos
      Também foi difícil encontrar um produto com custo-benefício próximo da qualidade de construção, bateria e estabilidade do MacBook Air M1 básico
      Também leio mangás e revistas no iPad, e há anos não sei qual seria a alternativa no mercado de tablets; talvez eu conseguisse abrir mão do Apple Watch, mas ele simplesmente funciona bem e tem muitos acessórios de terceiros
      Hoje já passou a época de instalar uma ROM nova todo dia, e parece difícil vencer a Apple em estabilidade e facilidade de uso, o que é uma pena
    • Talvez o maior segredo desta indústria seja que duas pessoas conseguem produzir mais resultados do que as maiores empresas
      A única razão pela qual o emprego de todo mundo está seguro é que ninguém consegue descobrir exatamente quem são essas duas pessoas
    • Parece que todo mundo deixa passar o fato de que, embora fosse relativamente fácil para a Apple bloquear seus laptops, ela deixou a porta aberta para que outros sistemas operacionais e seu desenvolvimento fossem possíveis
      A Apple criou seu próprio silício e construiu a plataforma inteira; é difícil acreditar que deixar a possibilidade de rodar outros sistemas operacionais tenha sido um simples erro
      É claramente uma porta deixada aberta de propósito para desenvolvimento por terceiros, então é decepcionante ver esse clima de crítica à Apple
    • Não acho que a Apple seja obrigada a implementar um padrão só porque ele existe
      Por exemplo, oferecer suporte a uma implementação de Vulkan contínua exigiria recursos consideráveis e criaria pressão sobre o cronograma de lançamentos, então precisaria haver uma razão de negócio
      “Para evitar vergonha” provavelmente não seria suficiente
      O argumento da boa vontade da comunidade poderia existir, mas não acho que a Apple vá buscar a simpatia de pessoas que a chamam de “empresa podre de ganância por trás de vídeos de marketing politicamente corretos”
    • OpenGL é uma especificação moribunda baseada em um modelo de programação antigo e terrível, e os testes de conformidade da Khronos também têm aspectos estranhos e exagerados
      Os testes de conformidade não são open source, e a “conformance suite” separada no GitHub é baseada no dEQP do Google, não no conjunto interno de testes da Khronos
      É possível obter “certificação de compatibilidade com o padrão” mesmo com bugs e lacunas consideráveis na implementação
      A Apple só prometeu suporte ao OpenGL 3.1, e o driver OpenGL para M1 também foi reescrito como uma camada de emulação sobre Metal para manter apps existentes funcionando, mas ela não vai implementar versões mais novas do OpenGL, nem precisa
      Há muitas críticas possíveis à Apple, e ainda há muito espaço para melhorar a API Metal e suas ferramentas, mas não se importar com OpenGL é, neste caso, uma decisão bastante razoável

  • É interessante que o texto original não mencione a palavra “Apple” uma única vez, usando apenas “fabricante” e “grande empresa”
    Se foi intencional, fico curioso se foi por motivos legais

    • Talvez seja porque este não é um texto sobre a Apple
      O interesse não é a Apple, e sim fazer o Linux rodar corretamente na arquitetura M1/M2; se o alvo fosse Microsoft, Amazon ou Google, teria sido tratado da mesma forma

  • Foi divertido acompanhar as transmissões ao vivo mostrando o processo de desenvolvimento desse driver, e é um trabalho realmente impressionante