Uma nova era para os gráficos em sistemas ARM no Linux pode estar começando com a chegada do Tyr, um driver de GPU para placas ARM Mali escrito inteiramente em Rust. Nascido de uma colaboração de peso — Collabora, Arm e Google — o projeto leva a segurança e a modernidade de Rust para uma das arquiteturas de GPU mais utilizadas no mundo. Para quem está só de passagem: pense no Tyr como um “novo motor” mais seguro para dirigir as GPUs Mali no kernel.
Por que um novo driver em rust para a mali?
Rust é como colocar airbags e ABS de fábrica no código: a linguagem evita, de saída, categorias inteiras de bugs ligados a memória (buffer overflows, use-after-free, data races) que historicamente atormentam drivers escritos em C. Em termos práticos, isso tende a significar menos travamentos, menos brechas de segurança e uma base mais fácil de manter — exatamente o que você quer num componente tão crítico quanto o que conversa com a sua GPU. No caso do Tyr, a mensagem é direta: trazer a segurança de Rust para o stack gráfico do Linux em ARM Mali não é modinha; é engenharia de base para o longo prazo.
O que muda na prática
O Tyr é uma reescrita moderna do Panthor (o driver em C para GPUs Mali com firmware CSF), mantendo a mesma uAPI e até o mesmo “nome” exposto ao userspace — ou seja, a pilha de usuários (como Mesa) continua falando a mesma língua. Esse cuidado reduz o atrito de adoção e preserva compatibilidade enquanto o código evolui do lado do kernel. E há uma estratégia organizacional por trás: o trabalho acontece no novo “drm-rust” (a árvore dedicada para drivers e infraestrutura DRM em Rust), o que acelera a evolução coordenada entre infraestrutura e drivers. (Collabora | Open Source Consulting)
Para leitores que gostam de tradução simultânea: o Tyr “fala Panthor” para o userspace, mas sob o capô usa as abstrações seguras de Rust — um híbrido que combina continuidade para quem desenvolve aplicações com uma fundação mais robusta dentro do kernel.
O estado atual e os próximos passos
Transparência importa: a submissão inicial do Tyr ao kernel é um esqueleto — ainda não funcional — porque depende de abstrações que estão em andamento (como GPUVM). Na prática, essa versão não consegue inicializar o MCU da GPU, então pouca coisa “roda” por enquanto. Mas o “downstream” (ramo de desenvolvimento fora do upstream) está bem mais adiantado: já boota o MCU, faz VM_BINDs síncronos usando a GPUVM em desenvolvimento e realiza submissões triviais via as abstrações drm_scheduler e dma_fence; o que ainda falta é amadurecer áreas como gerenciamento de dependências entre submits, fair scheduling em software e power management. Por ora, testes de IGT existem, mas o suporte foi validado apenas no SoC rk3588, então não espere que funcione em qualquer outro chip neste momento.
Esse caminho incremental não é acaso. A ideia é subir pequenas partes do driver no upstream, evoluindo em conjunto com outras peças escritas em Rust (como Nova e rvkms), validando as abstrações em hardware de verdade e dando à comunidade um motivo concreto para revisá-las — afinal, nada mobiliza reviewers como um usuário real no fim da linha.
Por que isso importa para o ecossistema Linux (e para você)
Se você administra dispositivos ARM, mantém uma distro, cria jogos ou apenas gosta de um desktop estável, a chegada do Tyr é um daqueles marcos que não estouram champanhe na hora — mas que mudam o filme nos bastidores. Drivers mais seguros por padrão reduzem o custo de manutenção e o risco operacional ao longo dos anos. E, com um Linux ARM Mali driver em Rust avançando em paralelo a uma árvore dedicada (drm-rust), a comunidade ganha cadência e coordenação: várias equipes podem iterar sobre a mesma infraestrutura de Rust para gráficos, liberando features de forma mais previsível. (Phoronix)
Também há um simbolismo forte: Collabora, Arm e Google colocam capital humano — mantenedores, revisores, engenheiros — para tornar Rust for Linux algo cotidiano na pilha gráfica, não uma exceção curiosa. Esse “dream team” sinaliza seriedade e continuidade: não é um experimento isolado, é uma aposta estratégica no futuro do kernel.
Como acompanhar (e quando esperar algo utilizável)
O roteiro público já está traçado: consolidar a infraestrutura (GPUVM e afins), levar o Tyr à paridade de recursos com o Panthor e — aí, sim — oferecer um driver de produção para as Mali/Immortalis Valhall Gxxx baseadas em CSF. Enquanto isso, o código segue sendo refinado em ciclos curtos e revisões abertas, com patches e discussões nas listas. Se você é desenvolvedor de kernel ou de Mesa, vale mergulhar nas referências abaixo; se é usuário final, a melhor dica é acompanhar os changelogs das suas distros e dos kernels LTS quando o Tyr começar a amadurecer.
