O AMD R600 driver ganhou uma segunda vida graças a uma combinação improvável: décadas de hardware vintage e inteligência artificial de última geração. O GitHub Copilot foi utilizado para realizar uma limpeza técnica no driver Gallium3D R600 do kernel Linux, cobrindo as placas das séries HD 2000 a HD 6000, lançadas entre 2007 e 2010. A iniciativa sinaliza uma mudança silenciosa, mas significativa, na forma como a comunidade open source sustenta código legado.
59 commits e um assistente de IA no lugar do copiloto humano
O trabalho foi conduzido pelo desenvolvedor Gert Wollny, que publicou 59 commits focados exclusivamente na refatoração do código do compilador de shaders dentro do driver R600. Em cada um deles, as notas de commit registram explicitamente o uso do Copilot em modo automático para auxiliar na construção do código. Não é um experimento isolado, mas um processo sistemático de manutenção com IA como ferramenta declarada, algo que o próprio Phoronix destacou como ponto de inflexão na cultura de desenvolvimento do kernel.
O contexto é simples e ao mesmo tempo revelador: drivers de hardware antigo no Linux frequentemente dependem de uma única pessoa ou de um grupo pequeno para continuar funcionando. Quando o mantenedor sai, o driver apodrece. A IA entra como multiplicador de força, permitindo que um único desenvolvedor assuma o volume de trabalho que antes exigiria uma equipe. Para GPUs com quase duas décadas de mercado, esse modelo de sustentação talvez seja o único viável.
Torvalds abriu a porta, mas colocou a responsabilidade no lugar certo
A adoção do Copilot no kernel não aconteceu no vácuo. Linus Torvalds posicionou-se a favor do uso de IA no desenvolvimento do Linux, mas com uma condição inegociável: qualquer desenvolvedor que use IA para gerar ou refatorar código precisa marcar explicitamente essa contribuição. Mais importante, a responsabilidade por código com bugs permanece inteiramente com o humano que assina o commit, e não com a ferramenta. É uma política que reconhece a utilidade da IA sem abrir mão do controle de qualidade que o kernel exige.
Essa distinção importa. A comunidade Linux esteve dividida durante meses sobre como lidar com o avanço do vibe coding nos repositórios do kernel, especialmente após uma enxurrada de relatórios de bugs gerados por IA sem supervisão adequada. A política atual resolve o impasse de forma pragmática: usa a ferramenta, mas exige que o desenvolvedor teste e valide antes de publicar.
O futuro do R600: um galho chamado Amber2
Mesmo com a limpeza de código em andamento, a comunidade já discute o próximo passo para o driver R600: separar o suporte a essas GPUs em um branch legado chamado “Amber2”. A ideia é isolar o driver do codebase principal do Mesa, evitando que atualizações futuras na pilha gráfica quebrem acidentalmente o suporte a hardware dos anos 2000. É uma solução arquitetural sensata: quem ainda usa uma HD 5870 ou similar não precisa conviver com a instabilidade de um driver acoplado a um projeto em evolução constante.
Em 2025, manter vivo um driver para GPUs com quase 20 anos pode parecer nicho, mas o ecossistema Linux tem uma base significativa de usuários que dependem de hardware antigo em servidores, estações de trabalho reutilizadas e projetos de baixo custo. Para esse público, a diferença entre um driver mantido e um abandonado é a diferença entre um sistema funcional e uma máquina sem aceleração gráfica. O uso do Copilot pelo Gert Wollny não é apenas uma curiosidade técnica, mas um modelo que tende a se repetir: a IA como seguro de vida para o código que o mercado esqueceu, mas que ainda roda em produção mundo afora.
Fonte: Tom’s Hardware
Você também pode gostar dos artigos abaixo:
AMD EPYC e a guerra silenciosa das CPUs: por que a razão CPU‑GPU importa mais do que nunca
Carregar ROMs no Sega Genesis via vinil: o experimento maluco que quase funcionou
