- O patch adiciona suporte à arquitetura Turing (RTX 20/GTX 16) no driver nova-core, desenvolvido em Rust para o Kernel Linux 7.0.
- A atualização corrige o carregamento do firmware de segurança (FWSEC) usando o método PIO para inicializar o hardware corretamente.
- A solução foi projetada por engenheiros da NVIDIA para garantir que placas legadas funcionem com o novo subsistema de drivers.
- O sistema agora alterna de forma inteligente entre os métodos DMA e PIO, eliminando falhas de comunicação no boot da GPU.
- A funcionalidade estará disponível para o público geral com o lançamento da versão estável do Kernel Linux 7.0 em 2026.
O desenvolvedor Alexandre Courbot, da NVIDIA, enviou a nona versão do conjunto de patches que adiciona suporte às GPUs da arquitetura Turing (séries RTX 20 e GTX 16) ao driver nova-core. Este driver, desenvolvido em Rust, representa o futuro do suporte de código aberto para hardware NVIDIA, focando no uso do GSP (GPU System Processor) para gerenciar funções complexas da placa. O patch introduz a lógica necessária para inicializar o firmware de segurança em modelos que ainda dependem de métodos de comunicação legados, garantindo que o Kernel Linux 7.0 amplie sua compatibilidade com hardware moderno e seguro.
A novidade consolida o driver Nova como uma peça-chave na maior atualização gráfica do ano, que já prepara o terreno para a próxima geração de hardware de 2026, conforme acompanhamos anteriormente aqui no SempreUpdate.
O que isso significa na prática
Para o usuário, essa mudança é um passo fundamental para que placas NVIDIA mais antigas, como a popular série RTX 20, funcionem de forma eficiente com drivers de código aberto modernos. Na prática, o patch resolve um problema de “comunicação inicial”: antes de a GPU começar a processar gráficos, o Kernel precisa carregar um software interno (firmware) na placa. Em modelos mais novos, isso é feito de forma automática e rápida via memória (DMA), mas nas placas Turing, o processo exige um “empurrãozinho” manual do processador (PIO) para carregar o carregador de inicialização. Com essa atualização, o sistema consegue identificar automaticamente qual método usar, tornando a inicialização do hardware transparente e estável.
Detalhes da implementação
A implementação técnica no subsistema de GPU foca na distinção entre os métodos de carregamento de firmware via Programmed I/O (PIO) e Direct Memory Access (DMA). A equipe da NVIDIA descobriu que, embora o DMA seja o padrão para chips mais recentes (GA102 em diante), a arquitetura Turing e o chip GA100 possuem restrições específicas. O firmware de segurança (FWSEC) nessas placas exige uma etiqueta de início explícita que só pode ser enviada via PIO.
| Característica | Arquitetura Turing / GA100 | Arquitetura GA102+ (Ampere/Ada) |
| Método de Carga | PIO (Obrigatório para Bootloader) | DMA (Preferencial) |
| Registradores PIO | Visíveis para a CPU | Mascarados/Invisíveis |
| Dependência GSP | Alta (necessita firmware FWSEC) | Nativa |
| Linguagem do Driver | Rust (nova-core) | Rust (nova-core) |
O código foi estruturado utilizando as características de segurança da linguagem Rust, implementando traits como FalconDmaLoadable e FalconPioLoadable. Isso garante que o Kernel não tente usar um método de carregamento incompatível com o hardware, evitando falhas críticas durante o boot.
Curiosidades e bastidores da discussão
A discussão na LKML revelou um trabalho de investigação profunda conduzido por Alexandre Courbot e Timur Tabi. Inicialmente, as condições para escolher entre PIO e DMA não estavam claras para a comunidade. Os desenvolvedores precisaram “escavar” o comportamento do hardware para entender por que o PIO era obrigatório no estágio inicial das placas Turing. Houve um debate técnico sobre como isolar esse código, já que ele é específico para arquiteturas que estão se tornando legadas dentro do ecossistema NVIDIA. A solução final foi criar um “adaptador” que envolve o firmware DMA padrão, permitindo que ele seja injetado via PIO apenas quando necessário, mantendo o restante do driver limpo e moderno.
Quando isso chega no meu PC?
Considerando que os patches estão na nona revisão e integrados ao ramo de desenvolvimento para o Kernel Linux 7.0, a expectativa é que o suporte oficial seja consolidado na janela de mesclagem da próxima versão principal. Para usuários de distribuições Rolling Release (como Arch Linux ou openSUSE Tumbleweed), a novidade deve aparecer poucas semanas após o lançamento estável do Kernel Linux 7.0. Já em sistemas como Ubuntu ou Fedora, o suporte deve chegar nas versões de final de ano ou através de repositórios de kernels atualizados.
