- O patch resolve falhas em comandos de GPU que excedem 16 páginas de memória no subsistema GSP da NVIDIA.
- Instruções complexas agora são fatiadas automaticamente, garantindo estabilidade no envio de dados ao hardware.
- A solução foi desenvolvida pela NVIDIA em Rust, utilizando os novos tipos estruturados SplitState e SplitCommand.
- A mudança introduz o código de erro EMSGSIZE no kernel para melhor gestão de payloads e segurança na transmissão.
- A funcionalidade está integrada ao Kernel Linux 7.0-rc1 com previsão de chegada à versão estável em abril de 2026.
O desenvolvedor Eliot Courtney, da NVIDIA, submeteu a terceira versão de uma série de patches que introduz o suporte a registros de continuação (continuation records) no driver Nova-core. Essa atualização é fundamental para o subsistema GSP (GPU System Processor) da NVIDIA, permitindo que o Kernel Linux 7.0-rc1 processe comandos complexos que anteriormente excediam o limite de tamanho permitido pela fila de mensagens do firmware.
O patch foca em expandir a capacidade de comunicação entre o sistema operacional e o processador interno das GPUs modernas. Ao implementar tipos estruturados em Rust, como o SplitState e o SplitCommand, o driver agora consegue fragmentar automaticamente chamadas de procedimento remoto (RPCs) que ultrapassam 16 páginas de memória, garantindo que instruções de grande porte sejam entregues sem falhas ou corrupção de dados.
Esta melhoria é um desdobramento direto dos recentes refinamentos para as arquiteturas Blackwell e Hopper que acompanhamos aqui no SempreUpdate, consolidando a maturidade do driver Nova-core antes do lançamento final da série 7.0.
O que isso significa na prática
Para o usuário final e administradores de sistema, essa mudança representa uma maior estabilidade e compatibilidade com firmwares recentes da NVIDIA. O GSP é o “cérebro” dentro das placas de vídeo que gerencia tarefas de baixo nível; quando o driver precisa enviar uma configuração muito pesada, ele agora pode “fatiar” essa informação em pedaços menores.
Antes desse suporte, o driver poderia simplesmente falhar ao tentar enviar comandos excessivamente grandes. Agora, o sistema lida com isso de forma transparente: comandos pequenos continuam sendo enviados instantaneamente, enquanto os grandes são movidos para um buffer temporário e transmitidos em sequência, sem que o usuário perceba qualquer atraso.
Detalhes da implementação
A implementação técnica ocorre no driver Nova-core, que é a nova iniciativa de driver de GPU escrita em Rust para o Kernel Linux. O patch introduz o código de erro EMSGSIZE nas bibliotecas Rust do kernel, sinalizando quando uma mensagem é longa demais para os buffers padrão.
A lógica de envio utiliza o SplitState para monitorar o progresso da transmissão. Se o comando couber em 16 páginas (o limite padrão do GSP), ele é gravado diretamente na fila de comandos para manter a performance máxima. Caso contrário, o driver aloca um buffer de estágio (staging buffer), realiza uma cópia segura e despacha os fragmentos através do novo tipo ContinuationRecord. Além disso, foi incluído um mecanismo de tempo de espera (timeout) de um segundo para garantir que o driver aguarde espaço disponível na fila antes de desistir da operação.
Curiosidades e bastidores da discussão
Esta é a terceira revisão do código (v3), o que demonstra um processo rigoroso de revisão por pares na LKML. O autor rebaseou o trabalho sobre a branch drm-rust-next, indicando que o código está alinhado com as futuras mudanças do subsistema gráfico na transição para a série 7.0.
Um detalhe interessante nas trocas de e-mails é a colaboração interna na NVIDIA, com Zhi Wang realizando os testes de validação (Tested-by). A discussão também levou à organização alfabética das variantes de função de mensagem (MsgFunction), uma prática de higiene de código que facilita a manutenção futura e evita erros de duplicidade em drivers complexos.
Quando isso chega no meu PC?
Com a abertura da janela de mesclagem (merge window) do Kernel Linux 7.0, o recurso deve ser integrado à versão estável final prevista para meados de abril de 2026. Distribuições de “rolling release” como Arch Linux e openSUSE Tumbleweed devem ser as primeiras a entregar a novidade. Já para usuários de distribuições focadas em estabilidade, o suporte deve aparecer em ciclos de atualização de hardware no segundo semestre de 2026.
