Um esforço recente patrocinado pela FreeBSD Foundation está pavimentando o caminho para que o sistema operacional execute nativamente o AMD ROCm, a plataforma de computação em GPU da fabricante. O projeto, liderado pelo desenvolvedor e estudante Sourojeet Adhikari durante seu estágio na fundação, já resultou em modificações no fork do LLVM mantido pela AMD e avanços na integração do driver com o drm-kmod.
A plataforma ROCm, assim como o CUDA da NVIDIA, fornece o ecossistema necessário para que desenvolvedores utilizem o poder de processamento paralelo das GPUs em cargas de trabalho intensivas. Historicamente, essas ferramentas têm focado quase exclusivamente em Windows e nas distribuições Linux, deixando o FreeBSD com suporte nativo muito limitado.
O trabalho em andamento busca alterar esse cenário, permitindo que servidores e estações de trabalho equipadas com o sistema BSD possam acelerar tarefas de aprendizado de máquina, processamento de dados e simulações complexas.
O que isso muda na prática
Para a maioria dos usuários de computadores pessoais, a placa de vídeo (GPU) serve principalmente para renderizar gráficos e jogos. No entanto, o hardware das GPUs é extremamente eficiente para realizar milhares de cálculos matemáticos simultaneamente.
Softwares de inteligência artificial, simulações de fluidos e análises de big data dependem desse tipo de aceleração. O ROCm é a resposta da AMD para facilitar a criação desses softwares. Trazer esse suporte para o FreeBSD significa que pesquisadores, administradores de sistemas e empresas poderão utilizar o sistema operacional como uma base robusta para computação de alto desempenho (HPC) e inteligência artificial, sem depender exclusivamente de distribuições Linux.
Desafios técnicos: LinuxKPI e kernel panics
O processo de portar um ecossistema complexo desenvolvido com o Linux em mente exige a adaptação de inúmeras chamadas e macros de baixo nível. Segundo a FreeBSD Foundation, uma parte significativa do trabalho envolveu lidar com o LinuxKPI, a camada de compatibilidade do kernel do FreeBSD que traduz ou fornece interfaces do kernel do Linux necessárias para determinados drivers.
Um dos bugs mais complexos enfrentados por Adhikari envolvia uma diferença sutil no tratamento de dados. A função class_register no Linux havia sido atualizada em versões mais recentes para aceitar uma estrutura constante (const). O código do kernel da AMD portado esperava esse comportamento moderno, enquanto a implementação do LinuxKPI no FreeBSD ainda aguardava uma estrutura mutável. Essa divergência de expectativa resultava em um kernel panic direto.
Além de solucionar problemas críticos de tradução de chamadas, o desenvolvimento exigiu a criação de funções temporárias (stubs) para rotinas específicas do Linux que ainda não existem no FreeBSD, como certos comportamentos de suspensão de energia que não eram estritamente necessários para o funcionamento inicial da computação em GPU.
Estágio atual e próximos passos
O projeto não representa, neste momento, um lançamento estável pronto para produção. Trata-se de um trabalho de base contínuo.
De acordo com o desenvolvedor, a equipe está se aproximando de um marco fundamental: executar uma carga de trabalho simples de adição de vetores. Atualmente, o driver já é capaz de ser linkado, carregado e executado, embora ainda existam problemas no espaço do usuário (userspace) que precisam ser resolvidos antes que softwares reais possam tirar proveito da GPU.
Alguns dos patches criados para o LLVM já foram enviados e aceitos no upstream, enquanto outras partes do código continuam em fase de revisão e fusão. O próximo grande desafio técnico no horizonte do projeto é explorar e implementar o suporte ao Gerenciamento de Memória Heterogênea (HMM – Heterogeneous Memory Management) no FreeBSD, um requisito crítico para operações mais complexas de computação em placa de vídeo.
