Alex Deucher da AMD assumiu o palco na XDC2014, que foi realizada hoje na França para providenciar novidades quanto a nova estratégia de drivers unificados sob código aberto. Comparando com o que foi anunciado anteriormente nesse ano, há mudanças notáveis, e no geral muito excitantes para os consumidores Linux da AMD, tanto para os que usam drivers de vídeo de código aberto quanto os de código fechado, já que ambos vão partilhar a mesma base do driver dentro do Kernel (código aberto).

Em março eu (Michael Larabel) escrevi exclusivamente sobre essa nova e interessante estratégia aberta da AMD que está sendo explorada. Aquelas informações vieram graças a um encontro com representantes da AMD durante a “Game Developer’s Conference” em São Francisco. O sentimento de progressão hoje é tão grande quanto o daquele artigo, mas há algumas diferenças.

Alex Deucher of AMD’s open-source team.

Voltando aquele artigo a ideia da estratégia do driver unificado era de que ambos os drivers tanto o de código fechado quanto o de código aberto funcionariam a partir da base de um driver no Kernel… Mas funcionando de forma um pouco diferente do já estabelecido driver Radeon DRM (Direct Rendering Manager). Ambos os drivers serão executados sob o mesmo driver no Kernel, mas o Catalyst irá basicamente tornar-se uma opção de driver fechado para funcionar apenas espectro de usuário. Para os fãs do driver de código aberto Gallium3D, vocês ainda poderão usar ele com esse novo driver aberto e unificado, no entanto para melhor performance do OpenGL será necessário utilizar o driver fechado Catalyst.

As boas novas é que a AMD continua progredindo no processo das funcões gerais, mas haverá um ponto de transição que vai afetar apenas futuras gerações de periféricos. Essa talvez seja a maior mudança nessa estratégia de driver unificado da AMD, comparando com as informações disponíveis desde março isso vai resultar em um driver totalmente novo dentro Kernel. Os dois drivers da AMD não serão executados de forma ao já existente Radeon DRM, como antecipado, mas será gerado um driver completamente novo. Esse novo driver da AMD de código aberto dentro do Kernel será inspirado parcialmente no já existente, mas haverá várias mudanças que ainda serão reveladas.

Todas as novas placas de vídeo terão suporte nesse novo driver de código aberto, mas novas GPUs não serão adicionadas ao já existente driver Radeon– o driver de código aberto atual. Esse novo driver é baseado no código do driver Radeon DRM e o Alex explicou que eles usaram Processadores Gráficos da série Sea Islands para testar protótipos do novo driver do Kernel, mas quando ele for mesclado ao Kernel pelo Git e estiver em produção, funcionará apenas com as placas de vídeo de séries acima das R9 290. “Não há planos para habilitar suporte a nenhum ASICs que já tenha suporte no Radeon.”

Além dos drivers de código aberto e fechado da AMD compartilharem o mesmo driver no Kernel, os dois também usarão a mesma biblioteca DRM ioctl wrapper (libdrm), e o mesmo driver DDX (X.Org). O driver compartilhado X.Org vai usar aceleração de código GLAMOR por padrão para ambas implementações – GLAMOR é a razão de se produzir gráficos 2D no driver de aceleração do X.Org em vez do OpenGL. No final das contas o Catalyst se tornará um driver usado apenas por usuários finais que necessitem das últimas versões do OpenGL ou para executar computações/OpenCL. O Catalyst vai se comunicar com o resto dos drivers abertos, enquanto os que querem executar apenas drivers abertos podem usar o Gallium3D no seu lugar, juntamente com o Mesa e Clover, etc.

Nenhum código do Catalyst será publicado, o novo driver será baseado no já existente Radeon. O novo driver Linux da AMD esta previsto para começar a ser publicado nesse outono (EUA). Graças a grande reviravolta na sua estratégia de driver aberto que funcionará com os novos periféricos que ainda não foram lançados, imagino que os primeiros periféricos a utilizarem esse novo driver serão as placas de vídeo da série 300, de codinome “Pirate Islands”. As placas Pirate Islands da AMD serão lançadas em 2015 para suceder as famílias Southern/Sea/Volcaninc Islands.

Em termos de novos designs, me informaram, “O novo driver está sendo amplamente reestruturado para funcionar com os novos lançamentos em vez de ASICs de famílias antigas. Em vez de ter rotinas de especialização diferentes para cada família, haverão tabelas para cada IP (UVD, VCE, DCE, GFX, etc.) cada ASIC tem uma API comum para carregar e inicializar os módulos apropriados para aquele ASIC.”

Essa mudança tem o potencial de ser amplamente vitoriosa se executada de forma correta. Reduzindo de novo a participação do driver Catalyst para uma pequena porção de usuários, esses usuários não precisarão mais esperar por uma nova versão do Catalyst para atualizarem o seu servidor gráfico X.Org ou a ABI do Kernel Linux já que agora essas partes estão em código aberto… E as principais funções do Kernel Linux não permitirão a “quebra” da ABI da esfera de usuário que poderia causar problemas com o Catalyst nesse novo modelo. Esse novo driver gráfico também permitirá o Catalyst a funcionar mais facilmente com o Mir (Ubuntu Touch) ou Wayland – agora o DRM/KMS podem ser usados pelo Catalyst, mas ele ainda precisará oferecer o suporte necessário as extensões EGL. Todas essas novidades também servem para os planos futuros que AMD tem sobre o HSA, também de código aberto.

Para essa nova estratégia realmente funcionar, a AMD precisa (se já não estiver fazendo por debaixo dos panos) aumentar seus investimentos nos projetos de código aberto. Agora com o Catalyst também dependendo do futuro driver DRM, eles precisam habilitar e concluir o suporte aos novos periféricos de forma decente antes deles serem lançados – assim o código pode alcançar o Kernel antes do hardware ser disponibilizado para venda. Até agora o suporte de novos periféricos no driver aberto Radeon DRM tem sido geralmente concluídos pós-lançamento e só depois de algumas semanas que eles alcançam versões estáveis do Kernel. É possível que o novo driver Catalyst também venha com o driver DRM (2 em 1) atualizado de maneira amigável a instalação DKMS? Nós veremos. Eles também precisarão fazer alguma coisa em relação as empresas que demoram para trocar de Kernels, como a SUSE Linux Enterprise, Red Hat Enterprise Linux, etc, então eu não estaria surpreso se o novo driver Catalyst para Linux também incluir uma versão rapidamente modificada do driver aberto compatível com DKMS para ser aplicado em Kernels antigos, mas nenhuma dessas informações foi confirmada.

A AMD também precisará apressar o passo porquê no geral, considerando que o suporte ao driver aberto da ADM R9 290 começou a ser trabalhado apenas recentemente, e mesmo assim placas de vídeo “top-end” da AMD com o driver de código (aberto) nem sempre funcionam com reclock, o que resulta em números de performance baixos. A parte triste é que a série Radeon R9 290 tem agora um ano de idade, então vamos torcer para que essa nova estratégia de driver aberto unificado lidere para mais pessoas trabalhando nesse driver DRM no Kernel. Para finalizar, tenho que dizer que no mínimo tempos estão interessantes.

Quando o novo driver do Kernel Linux da AMD for lançado, tenha certeza de que ele será testado de forma sistemática pelo Phoronix.