Confira !!
Embora o Habana Labs seja conhecido por seu driver de kernel Linux de código aberto e upstream para seus aceleradores de treinamento / inferência de IA com o código em que eles estavam trabalhando como uma start-up antes mesmo de serem adquiridos pela Intel, continua a causar atrito que eles dependem do espaço do usuário em componentes de código-fonte fechado, como seu compilador. Isso, por sua vez, está causando problemas novamente para as mudanças que o driver do kernel do Habana Labs planejou pousar com o próximo ciclo do Kernel Linux 5.15.
Na última quinta-feira, a solicitação de pull de atualizações de driver do Habana Labs foi enviada para "char / misc" para a fila antes da janela de mesclagem do Linux 5.15 abrir em uma semana ou mais. Por falta de um subsistema AI / acelerador ainda, o driver do kernel do Habana Labs continua a viver dentro da área char / misc "catch all" do kernel.
Essa solicitação de pull introduziu uma nova API para o espaço do usuário exportar como um objeto DMA-BUF, permitir a espera de vários envios de comandos, suporte a despejo de estado para depuração e uma variedade de outras alterações. Mas são as mudanças em torno do DMA-BUF que acabaram abrindo uma lata de vermes.
Greg Kroah-Hartman como o mantenedor char / misc puxou as mudanças de driver do Habana Labs em seu código Git "-next" antes da janela de mesclagem do Linux 5.11. No entanto, o mantenedor do subsistema DRM David Airlie "NAK'ed" [não reconhecer] o código . Ele se opôs a este código sendo colocado na fila para fusão com base nas alterações DMA-BUF / P2P.
Estamos abrindo uma grande lata de worms (alguns diriam que o driver do habanalabs foi aberto), mas isso nos coloca na situação de que, se um fornecedor de GPU apenas alegar que seu hw é um acelerador de "vetor", ele pode usar Greg para ignorar todo o trabalho isso foi feito para garantir que tenhamos sustentabilidade a longo prazo. Não quero que os drivers na árvore usando dma-buf interajam com outros drivers quando não temos acesso a um projeto de espaço do usuário para validar as suposições do driver do kernel.
Em última análise, o problema decorre de drivers de kernel de DRM / gráficos que requerem software de espaço do usuário de código aberto para exercitar todas as APIs de espaço do usuário expostas por drivers de kernel. Isso provou ser benéfico para fins de teste, manutenção de código e garantia de que os usuários não estejam presos ao uso de software de código fechado no espaço do usuário para aproveitar algum recurso do driver do kernel, etc. Mas no caso dos Laboratórios Habana driver, ele reside em outro lugar no kernel (char / misc) e não possui uma solução de espaço de usuário de código aberto adequada, enquanto deseja usar o código em torno do que é esperado dos drivers de kernel DRM (DMA-BUF).
Assim, o (co-) mantenedor do DRM David Airlie recuou contra essas mudanças que permitiriam o suporte DMA-BUF / ponto a ponto devido aos requisitos de fonte de espaço do usuário. Esse problema com o driver do kernel do Habana Labs foi discutido anteriormente no crescente número de drivers do AI Accelerator reacende o debate sobre o driver do kernel Linux .
Greg já removeu as alterações do driver do kernel do Habana Labs que estavam programadas para o Kernel Linux 5.15. Veremos se uma nova solicitação pull vem com todas as alterações, mas o DMA-BUF / P2P funciona.
O co-mantenedor do DRM e mantenedor do driver gráfico do kernel da Intel, Daniel Vetter, também concordou com as objeções de David Airlie. Portanto, embora o Habana Labs agora seja propriedade da Intel, ainda há mais trabalho a fazer e, idealmente, ver uma solução de espaço do usuário totalmente de código aberto para seus aceleradores de IA ... Veremos se / quando isso acontece, dada a competitividade em esse espaço, embora a Intel normalmente seja bastante aberta com seu código.
Até a próxima !!
Nenhum comentário:
Postar um comentário