FERRAMENTAS LINUX: A AMD está trabalhando silenciosamente no novo suporte de driver de GPU Linux bloco por bloco

sábado, 19 de fevereiro de 2022

A AMD está trabalhando silenciosamente no novo suporte de driver de GPU Linux bloco por bloco


 Confira  !!

Os engenheiros de driver gráfico Linux da AMD têm trabalhado no suporte de driver para novos processadores gráficos e agora os patches estão nos estágios iniciais de publicação. No entanto, devido a mudanças no manuseio do driver, é bem diferente desta vez, onde no passado eles lançaram um grande conjunto de patches sob algum codinome colorido suspeito em um esforço para ocultar seu trabalho de ativação de hardware.

Com o suporte da série Radeon RX 6000 em bom estado (assim como muitos outros IDs PCI para a possível atualização do Navi 2/ rumores de GPUs RX 6x50) vários IDs de atualização Navi 2), suporte ao driver VanGogh em boa forma para o Steam Deck e o suporte Yellow Carp / Rembrandt se estabelecendo para as próximas APUs móveis da série Ryzen 6000, para nenhuma surpresa real, eles já internamente estar trabalhando no que vem a seguir... Além do fato de que o esforço real de habilitação de hardware normalmente começa muito antes do lançamento do produto ou até mesmo dos patches iniciais de driver de código aberto, devido às mudanças abundantes a cada nova geração, além de precisar passar por vários processos legais e processos de revisão interna antes da publicação do novo código de habilitação.

Desta vez, com suporte a novo hardware, ele está saindo de forma mais sutil, mas ainda o suficiente para aparecer no meu radar com o monitoramento implacável de listas de discussão e repositórios Git durante as semanas de trabalho de cem horas. Nos últimos anos, a AMD forneceu suporte a drivers Linux de pré-lançamento, para novas habilitações de GPU / ASIC, eles geralmente enviaram o suporte inicial como uma longa série de patches e criaram alguns codinomes coloridos como Sienna Cichlid, Yellow Carp, Dimgrey Cavefish , e outros. Esses codinomes específicos do Linux foram para ajudar a ocultar o codinome do produto subjacente, mas também usados ​​no caso dos nomes de arquivos de firmware da GPU e outras áreas no código. Essa abordagem, no entanto, parece ser em grande parte uma questão do passado.

Você pode se lembrar no ano passado do meu artigo sobre o driver AMDGPU revisando sua abordagem para enumeração de dispositivos . Essa alteração fundamental do driver é inicializar a placa gráfica com base nos blocos IP/hardware descobertos, em vez de segmentar os caminhos do código do driver com base apenas no ID PCI da placa gráfica. As GPUs AMD recentes suportam uma "tabela de descoberta de IP" que observa os diferentes blocos de hardware que compõem a GPU, desde o mecanismo gráfico até a codificação/decodificação de vídeo, gerenciamento do sistema/gerenciamento de energia, segurança e outros blocos de IP.

Esse retrabalho no driver AMDGPU já foi alinhado ao kernel do Linux, de modo que, para as GPUs mais recentes, já está adotando essa abordagem de "descoberta baseada em IP" ao acender a GPU para analisar essa tabela e obter os respectivos caminhos de código em vez de ser explicitamente feito com base no ID PCI. A rota de descoberta baseada em IP é uma vitória para informações menos codificadas no driver e efetivamente torna o driver mais modularizado e mais limpo. Isso também pode ajudar com a AMD no lado do SoC personalizado, possivelmente precisando de menos alterações de driver se for apenas uma questão de construir uma nova combinação de blocos suportados existentes. Mas, como observado no ano passado, isso também beneficiaria a AMD ao trazer um novo suporte de hardware, pois pode ser feito de maneira mais modular, em vez de uma grande série de patches sequenciais.


O driver AMDGPU Linux está se afastando das configurações predefinidas/estáticas para o driver e mais para as tabelas de "descoberta" para descobrir os diferentes blocos de hardware/IP encontrados na GPU que está sendo carregada.

Nos últimos dias, surgiram várias séries de patches diferentes para trazer os novos blocos IP gráficos da AMD Radeon, como o SMU 13.0.5 para a sua unidade de gerenciamento de sistema, codificação de vídeo VCN 3.1.2, PSP 13.0.5 para a segurança e GC 10.3.6, entre outros.

Parece que este é o caminho a seguir para suas novas GPUs e algumas menções a "ASIC em diante" e hardware futuro chegando em pequenas séries de patches exclusivas, em vez da grande série inicial de patches normalmente vista como parte de sua nova habilitação de hardware.

Os divertidos "codinomes Linux" coloridos e suspeitos parecem ter acabado...


Os nomes dos arquivos de firmware também assumem o nome/versão do bloco em vez dos codinomes suspeitos nesses novos blocos de IP que estão sendo trazidos.

Para encurtar a história, parece que a AMD está avançando no desenvolvimento de seu novo suporte de hardware agora ao longo dessa abordagem de descoberta baseada em IP para seu driver Linux de código aberto. Das várias séries de patches postadas até agora, nenhuma surpresa de hardware encontrada até agora, mas ainda não há código suficiente para uma grande atualização da GPU. Quanto à função desses diferentes blocos sendo habilitados, é possível trabalhar antecipadamente em hardware baseado em RDNA3. Com o driver AMDGPU já tendo o hardware GPU lançado suportado, além de ter adicionado vários IDs PCI "refresh" RDNA2, bem como VanGogh e Yellow Carp (Rembrandt), é bem possível que os primeiros patches estejam começando a fluir para RDNA3 que a AMD reafirmou será lançado no segundo semestre de 2022.

Independentemente da recente série de patches para novos blocos de IP, se a AMD quiser um bom suporte a GPU RDNA3 no lançamento no desktop Linux com o código do driver upstream, eles precisarão obter o código do driver GPU de última geração e pronto para este verão. Devido à cadência dos lançamentos do kernel Linux (e do Mesa para OpenGL/Vulkan), bem como aos ciclos de lançamento das distribuições Linux proeminentes, neste verão devemos ver mais atividades de patch apontando claramente para o RDNA3 se eles estiverem buscando uma boa saída suporte pronto para uso no lançamento com o código upstream em vez de apenas seu conjunto de drivers empacotados voltados para a empresa.

De qualquer forma, é ótimo ver mais código Linux de código aberto da AMD.











Até a próxima !!

Nenhum comentário:

Postar um comentário