Dirt 3 pulou de 110 para 860 FPS. Não é overclock, não é uma GPU nova. É o kernel do Linux fazendo nativamente o que antes dependia de gambiarras no Wine.

O que aconteceu é surreal quando você para pra pensar: os desenvolvedores do kernel Linux literalmente implementaram mecanismos de sincronização do Windows NT dentro do kernel. Não como uma camada de tradução, não como um hack temporário — como um driver oficial, aceito no mainline, carregado por padrão em todo Steam Deck atualizado.

O nome disso é NTSYNC, e se você joga no Linux (ou pensa em migrar), precisa entender o que mudou.

O problema que ninguém sabia que existia

Pra entender por que o NTSYNC importa, precisa entender como o Wine funciona por baixo dos panos.

O Wine convence programas Windows de que estão rodando no Windows. Quando um jogo chama uma API do Windows, o Wine intercepta e traduz pra algo que o Linux entende. Funciona surpreendentemente bem — a ponto do Proton (a versão turbinada do Wine feita pela Valve) rodar mais de 16.000 jogos Windows no Steam Deck.

Mas tem um gargalo escondido: sincronização de threads.

Jogos modernos são bestas multi-threaded. Eles precisam coordenar dezenas de threads fazendo coisas diferentes — renderização, física, áudio, IA, rede. No Windows, isso é feito via mecanismos de sincronização do NT kernel: mutexes, semáforos, eventos. São primitivas que o sistema operacional resolve em nanossegundos.

No Linux, o Wine precisava emular tudo isso no wineserver — um processo separado que recebia chamadas via socket. Cada operação de sincronização virava uma ida-e-volta via IPC (inter-process communication). Em um jogo que faz milhares dessas operações por segundo, o overhead se acumula de um jeito brutal.

Era como trocar mensagens de texto pra decidir quem passa primeiro num cruzamento, em vez de ter um semáforo.

Esync, Fsync: as gambiarras que funcionaram (mais ou menos)

A comunidade não ficou parada. Ao longo dos anos, surgiram duas soluções pra contornar o gargalo do wineserver:

Esync (Event-based Synchronization)

O esync substituiu as chamadas ao wineserver por eventfd do Linux — file descriptors do kernel usados pra sinalização. Funcionou razoavelmente bem, mas tinha um problema: cada objeto de sincronização consumia um file descriptor. Jogos complexos podiam atingir o limite do sistema, causando crashes aleatórios.

Já vi gente aumentando o ulimit de file descriptors pra 500.000 só pra rodar um jogo. Não exatamente uma solução elegante.

Fsync (Futex-based Synchronization)

O fsync foi um passo à frente. Usava futexes do Linux (Fast User-space Mutexes), que são mais eficientes que eventfd. O problema? Precisava de patches custom no kernel. Nenhuma distro mainline trazia fsync por padrão — você dependia de kernels modificados como o linux-tkg, o kernel customizado da Valve, ou patches do Proton.

Na prática, o fsync virou padrão no ecossistema Valve. Se você joga no Steam Deck ou usa Proton, já está usando fsync. E funciona bem. Mas “funcionar bem” e “funcionar corretamente” são coisas diferentes.

O fsync aproximava o comportamento do Windows, mas não era semanticamente idêntico. Operações como NtPulseEvent() e o modo “wait-for-all” do NtWaitForMultipleObjects() exigem controle direto sobre as filas de espera do kernel — algo que implementações em user-space simplesmente não conseguem fazer de forma confiável.

O resultado? A maioria dos jogos rodava bem. Mas alguns tinham micro-stutters inexplicáveis, deadlocks raros, ou comportamentos bizarros que nenhum benchmark captura mas que arruínam a experiência individual.

NTSYNC: a solução que parecia impossível

A história do NTSYNC começa com Elizabeth Figura, engenheira da CodeWeavers (a empresa por trás do Wine). Ela é, aliás, a mesma pessoa que desenvolveu o esync e o fsync. Depois de anos empurrando os limites do que era possível em user-space, chegou à conclusão óbvia: a única forma de fazer isso direito era colocar no kernel.

Em 2023, ela apresentou a proposta na Linux Plumbers Conference. A ideia era audaciosa: criar um driver que expõe um dispositivo /dev/ntsync, modelando diretamente a API de objetos de sincronização do Windows NT.

Parece loucura. O kernel Linux, bastião do software livre, incorporando um driver que existe exclusivamente pra rodar binários do Windows melhor? Sem benefício algum pra programas nativos do Linux?

Pois é. Em janeiro de 2026, o NTSYNC foi aceito no kernel 6.14. Mainline. Oficial.

Como funciona na prática

A arquitetura é elegante na sua simplicidade:

Antes (wineserver):
Jogo → Wine → Socket IPC → wineserver → Socket IPC → Wine → Jogo
(milhares de round-trips por segundo)

Depois (NTSYNC):
Jogo → Wine → syscall → /dev/ntsync (kernel) → retorno → Wine → Jogo
(operação direta, sem IPC)

Em vez de enviar requisições pra um processo separado via socket, o Wine agora faz syscalls diretamente ao driver do kernel. A diferença de latência é brutal — estamos falando de microsegundos vs nanossegundos, multiplicados por milhares de operações por frame.

O driver suporta todas as primitivas de sincronização do NT:

E mais importante: suporta NtWaitForMultipleObjects() com semântica correta — incluindo o modo wait-for-all que o fsync nunca conseguiu implementar direito.

Os benchmarks que quebraram a internet

Quando os primeiros benchmarks do NTSYNC apareceram, muita gente achou que era fake. Os números contra Wine vanilla (sem fsync/esync):

Preciso ser honesto aqui: esses números comparam com Wine vanilla, que quase ninguém usa pra jogar. Se você já usava Proton com fsync, os ganhos são mais modestos — mas ainda existem.

A real diferença do NTSYNC pra quem já usa fsync não aparece em gráficos de FPS. Aparece na ausência de problemas:

• Sem aquele micro-stutter aleatório a cada 30 segundos
• Sem deadlocks raros que travam o jogo na pior hora possível
• Sem comportamentos bizarros em jogos que usam padrões incomuns de sincronização
• Sem precisar de patches custom no kernel

Esses são os bugs que não aparecem em benchmarks mas que fazem você voltar pro Windows depois de uma semana de frustração.

Wine 11: muito mais que NTSYNC

O Wine 11, lançado em março de 2026, trouxe o NTSYNC como estrela principal, mas veio acompanhado de mudanças que merecem atenção:

WoW64 completo

Finalmente, um único binário 64-bit roda aplicações Windows de 32 e 64 bits. Chega de instalar bibliotecas multilib, chega de manter dois prefixos separados. Isso simplifica brutalmente a configuração e reduz o consumo de memória.

A contrapartida: apps 32-bit que usam OpenGL puro (não DirectX/Vulkan) podem ter uma regressão de performance nesse modo. Na prática, isso afeta uma fatia mínima dos jogos, já que praticamente tudo passa por DXVK (DirectX → Vulkan) ou vkd3d.

EGL como backend OpenGL padrão

No X11, o Wine 11 troca o GLX pelo EGL como backend OpenGL padrão. Parece um detalhe técnico irrelevante, mas facilita a transição pra Wayland e unifica o código gráfico.

Vulkan 1.4

Suporte a Vulkan 1.4 no Wine, acompanhando as GPUs mais recentes. Importante pra jogos novos que dependem de features específicas dessa versão.

Decodificação H.264 por hardware

Via Direct3D 11 com Vulkan Video. Cutscenes e vídeos in-game agora decodificam na GPU em vez de depender de software — menos CPU roubada do gameplay.

Wayland melhorado

Clipboard bidirecional, drag-and-drop, e melhor tratamento de modos de display. O Wayland no Wine está finalmente ficando usável de verdade.

A engenheira por trás de tudo

Vale parar um segundo pra reconhecer Elizabeth Figura, da CodeWeavers. Ela não é uma figura aleatória nessa história — é a pessoa que criou o esync, depois o fsync, e finalmente o NTSYNC. Três gerações de soluções pro mesmo problema, cada uma aprendendo com os limites da anterior.

Na apresentação da Linux Plumbers Conference em 2023, ela explicou a motivação de forma direta: “A sincronização NT historicamente dependia de RPC, mas aplicações modernas usam essas APIs intensivamente, e o overhead se tornou um gargalo.” Traduzindo do engenheirês: os jogos fazem tantas chamadas de sincronização que o caminho antigo simplesmente não aguenta.

O fato de uma única engenheira ter desenvolvido as três soluções dá ao NTSYNC uma vantagem que vai além do código — ela conhece intimamente cada falha dos sistemas anteriores e construiu o novo driver pra resolver todas elas. Não é um projeto de comitê. É o trabalho de alguém que viveu o problema por anos.

O efeito Steam Deck

Nada disso teria acontecido sem o Steam Deck.

A Valve não só financiou o desenvolvimento do Proton como empurrou o Linux gaming pra um lugar que ninguém imaginava possível há cinco anos. Em março de 2026, o Linux atingiu 5% da base de usuários do Steam — pode parecer pouco, mas representa dezenas de milhões de jogadores.

O Steam Deck roda SteamOS, que é basicamente Arch Linux com uma interface customizada. A Valve integrou o driver NTSYNC no SteamOS 3.7.20 beta, carregado por padrão. Ou seja: se você tem um Steam Deck atualizado, já está usando NTSYNC sem fazer nada.

Isso é significativo porque o Steam Deck se tornou o benchmark que os desenvolvedores de jogos testam. Quando um dev garante que o jogo roda no Deck, está implicitamente garantindo que roda no Linux. E com NTSYNC no kernel, a barreira entre “roda” e “roda bem” praticamente desapareceu.

Como ativar o NTSYNC no seu Linux

Se você está numa distro com kernel 6.14 ou superior, o processo é simples:

# Verificar versão do kernel
uname -r

# Carregar o módulo
sudo modprobe ntsync

# Verificar se o dispositivo existe
ls -la /dev/ntsync

# Para carregar automaticamente no boot
echo "ntsync" | sudo tee /etc/modules-load.d/ntsync.conf

Distros com suporte nativo (maio 2026):

Ainda sem suporte:

• Ubuntu 24.04 LTS (kernel 6.8) — precisa esperar o 26.04
• Debian 12 (kernel 6.1) — precisa do Debian 13

No Wine 11 ou Proton 11, o NTSYNC é detectado automaticamente. Se o /dev/ntsync existe, ele usa. Senão, faz fallback pra fsync.

O que isso significa pro futuro do Linux gaming

O NTSYNC estabeleceu um precedente importante: o kernel Linux pode e vai incorporar features que existem exclusivamente pra melhorar a compatibilidade com software Windows. Isso era impensável há uma década.

E não deve parar por aí. Já existem discussões sobre trazer outras primitivas do Windows pro kernel — como I/O completion ports (usados pesadamente por engines de rede de jogos online) e partes do modelo de memória virtual do NT.

Cada uma dessas adições reduz a distância entre “rodar no Linux via Wine” e “rodar nativamente”. Em algum momento — e eu diria que estamos mais perto do que parece — a diferença vai ser imperceptível pra 99% dos jogos.

O fim do suporte ao Windows 10 em outubro de 2025 já empurrou muita gente pro Linux. Com NTSYNC, Wine 11, e o ecossistema Steam Deck provando que funciona, a migração não é mais questão de se, mas de quando.

Enquanto isso, se você ainda acha que “Linux não serve pra jogar”, eu sugiro testar o Dirt 3 no Wine 11 e ver aqueles 860 FPS piscando na tela. A conversa muda rápido depois disso.

Ah, e se você quiser um rabbit hole técnico pra se perder num fim de semana: leia o código do driver NTSYNC no kernel. São poucas centenas de linhas de C. Pra algo que melhora performance em centenas de porcentos, é impressionantemente enxuto. Às vezes a solução certa é simples — só precisa de alguém com experiência suficiente pra ver onde colocar ela.

Fonte de inspiração: Linux gaming is faster because Windows APIs are becoming Linux kernel features — XDA Developers