FPS médio de 120, 144 ou mais — e mesmo assim o jogo engasga por frações de segundo em momentos específicos. O personagem teleporta ligeiramente, a animação fica desconexa, e o pior: trocar a GPU por uma mais potente não resolve. Esse é o retrato clássico do shader compilation stutter, um dos tipos de engasgo mais frustrantes porque ataca justamente quem tem hardware forte e esperava uma experiência perfeitamente fluida.
Diferente da maioria dos problemas de performance, shader compilation stutter não é resolvido com mais poder de GPU — é um problema de arquitetura de engine e de como (e quando) o jogo prepara os programas gráficos antes de usá-los. Este guia explica exatamente o que é, por que hardware potente não escapa dele, e o que de fato ajuda.
O que é exatamente o shader compilation stutter
Entender essa mecânica em detalhe é o primeiro passo para parar de tratar esse engasgo como um defeito de hardware e começar a tratá-lo pelo que realmente é: uma etapa de preparação que todo jogo precisa fazer em algum momento, cedo ou tarde, na sua máquina específica.
Shaders são pequenos programas que rodam na GPU e determinam como cada material, luz e efeito visual deve ser desenhado na tela. Um jogo moderno tem milhares de combinações possíveis de shaders — uma para cada combinação de material, iluminação e efeito que pode aparecer em uma cena. Antes de a GPU conseguir desenhar algo pela primeira vez, esse shader específico precisa ser compilado — traduzido do código genérico da engine para instruções que a sua GPU específica entende.
Quando essa compilação acontece durante o jogo, no exato momento em que o shader é necessário pela primeira vez, o motor gráfico precisa pausar a renderização por alguns milissegundos até centenas de milissegundos para terminar o trabalho — e é exatamente essa pausa que sentimos como um engasgo. O nome técnico para isso, usado por desenvolvedores e em ferramentas de diagnóstico como o Special K, é justamente shader compilation stutter.
Por que hardware potente não elimina esse tipo de stutter
A compilação de um shader é um trabalho pesado de CPU (não de GPU), e mais especificamente um trabalho que, em muitas implementações, roda em apenas uma ou duas threads da CPU, de forma síncrona com o restante do jogo — ou seja, o jogo literalmente espera a compilação terminar antes de continuar desenhando o próximo frame. Uma GPU mais rápida não ajuda porque ela não é o componente fazendo esse trabalho, e um processador com mais núcleos só ajuda se a engine do jogo foi programada para distribuir a compilação entre vários núcleos — o que nem toda engine faz.
É por isso que é comum ver um PC com RTX 4090 e um processador topo de linha engasgando da mesma forma (às vezes até pior, por rodar em resoluções e taxas de quadro mais altas, expondo o stutter com mais nitidez) que um PC bem mais modesto rodando o mesmo jogo. O gargalo não é capacidade de renderização — é o tempo de compilação de um shader específico na primeira vez que ele é necessário.
Unreal Engine e o histórico problema de PSO caching
Jogos feitos em Unreal Engine 4 e 5 ficaram particularmente conhecidos por esse tipo de stutter em lançamentos como Jedi Survivor, Immortals of Aveum e vários outros títulos AAA recentes. O motivo técnico é o gerenciamento de PSOs (Pipeline State Objects) — a forma como a Unreal Engine organiza as combinações de shaders. Por padrão, a engine compila esses PSOs sob demanda, exatamente quando são encontrados pela primeira vez durante o jogo, em vez de compilá-los todos antecipadamente.
A Epic Games introduziu um sistema de PSO Precaching nas versões mais recentes da Unreal Engine 5 (5.3 em diante) que permite à engine identificar e compilar esses shaders com antecedência, antes do momento em que seriam necessários — mas depende de cada estúdio implementar corretamente esse sistema no próprio jogo. Jogos lançados com PSO Precaching bem implementado (alguns títulos mais recentes já adotam) têm bem menos desse tipo de engasgo do que títulos mais antigos ou lançados às pressas sem esse cuidado.
Como confirmar que é isso e não outro tipo de stutter
Fazer essa confirmação antes de aplicar qualquer solução evita perder tempo testando ajustes que não têm relação nenhuma com a causa real do seu engasgo específico.
O padrão mais característico é a intensidade maior nas primeiras horas de jogo, ou logo depois de uma atualização do jogo ou do driver de vídeo (que invalida caches de shader existentes). Áreas, efeitos visuais e situações nunca vistas antes na sessão atual são os gatilhos mais comuns — entrar em uma nova região do mapa, ativar uma habilidade específica pela primeira vez, ou encontrar um tipo de inimigo novo. Se você joga a mesma seção repetidamente, o engasgo tende a diminuir e eventualmente desaparecer, porque o shader já foi compilado e fica em cache.
Isso é diferente de gargalo de CPU (que se repete de forma consistente sempre que a mesma situação de carga acontece, sem melhorar com repetição) ou de VRAM insuficiente (que se manifesta mais como travamentos ao carregar texturas do que como micro-engasgos pontuais). Se o mesmo trecho do jogo engasga na primeira vez e roda liso na segunda, é praticamente certeza de shader compilation stutter.
Pré-compilação de shaders: sempre aceite quando o jogo oferecer
Vários jogos — Cyberpunk 2077 e Hogwarts Legacy são exemplos conhecidos — oferecem uma etapa de pré-compilação de shaders antes mesmo de você chegar ao menu principal, geralmente identificada como “Compilando shaders” ou “Optimizing shaders” na tela de carregamento inicial. Esse processo pode levar de 1 a 10 minutos dependendo do jogo e do hardware, mas compila antecipadamente boa parte dos shaders que seriam compilados aos poucos durante o jogo, trocando uma espera única e previsível por dezenas de micro-engasgos espalhados pela sessão.
Vale sempre deixar esse processo terminar completamente em vez de pular ou fechar o jogo no meio — interromper a pré-compilação frequentemente resulta em ela recomeçar do zero na próxima vez que o jogo for aberto, em vez de continuar de onde parou.
O cache de shaders da GPU: por que nunca deve ser apagado por programas de limpeza
Depois de compilado uma vez, um shader fica armazenado em um cache mantido pelo driver da GPU (NVIDIA, AMD e Intel mantêm esse cache separadamente do cache específico do jogo), para que não precise ser recompilado em sessões futuras. Esse cache pode crescer para vários gigabytes em uma biblioteca grande de jogos — e é exatamente por parecer “espaço desperdiçado” que programas genéricos de limpeza de disco frequentemente o apagam, sem o usuário perceber, fazendo o stutter de compilação voltar como se o jogo tivesse acabado de ser instalado.
No painel de controle da NVIDIA (Gerenciar configurações 3D → Tamanho do cache de shader do programa) é possível verificar e ajustar o tamanho máximo desse cache — aumentá-lo em sistemas com bastante espaço em disco livre reduz a chance de shaders antigos serem descartados para abrir espaço para novos. O mesmo controle existe no Radeon Software (Configurações Gráficas → Cache de Shader) para GPUs AMD.
Shader pre-caching da Steam: como funciona e quando ajuda
Para jogos que usam Vulkan (incluindo praticamente todo jogo rodado via Proton no Steam Deck e no Linux), a própria Steam mantém um sistema de cache de shaders compartilhado entre jogadores: quando alguém compila um shader localmente, esse resultado pode ser compartilhado de volta para a comunidade Steam, para que outros jogadores com GPU semelhante baixem o shader já compilado em vez de compilar do zero. Isso é ativado por padrão na maioria das contas e explica por que jogos rodados via Proton frequentemente têm menos stutter de compilação na primeira sessão do que se esperaria.
Se notar stutter de compilação incomum logo na primeira sessão de um jogo Vulkan/Proton, vale verificar em Configurações da Steam → Shader Pre-Caching se a opção está ativada — ela vem habilitada por padrão, mas pode ter sido desativada manualmente em algum momento.
Quando a solução depende só de um patch do desenvolvedor
Esse é o cenário mais comum em lançamentos recentes de jogos AAA em Unreal Engine, e reconhecer que o problema está fora do seu controle evita horas de tentativa e erro sem resultado.
Em alguns casos, não existe ajuste do lado do jogador que resolva de verdade — o problema está na forma como o jogo foi programado para compilar shaders de forma síncrona (travando o frame principal) em vez de assíncrona (compilando em segundo plano enquanto o jogo continua rodando, mesmo que com uma textura simplificada temporária no lugar). Esse é um trabalho de engenharia do estúdio, geralmente feito via patch pós-lançamento depois que a comunidade reporta o problema em massa.
Se o stutter de compilação for severo mesmo depois de aplicar tudo listado acima, vale verificar o roadmap de patches do jogo ou o fórum oficial — jogos com esse problema documentado publicamente costumam receber correção de compilação assíncrona de shaders em algum patch depois do lançamento, já que é um dos tipos de reclamação mais comuns em reviews técnicos.
Como medir o impacto real com ferramentas de frametime
Como o shader compilation stutter aparece como picos pontuais de frametime em vez de queda constante de FPS, um contador de FPS médio simples não mostra o problema com clareza — é preciso olhar para o frametime frame a frame. O MSI Afterburner combinado com o RivaTuner Statistics Server (RTSS) permite ativar um gráfico de frametime em tempo real sobreposto ao jogo, mostrando picos isolados que um contador de FPS médio esconderia completamente.
Ferramentas mais avançadas como o Special K (voltada para jogadores mais técnicos, com suporte a diversos motores gráficos) chegam a identificar e registrar especificamente quando um pico de frametime coincide com uma nova compilação de shader, separando esse tipo de stutter de outras causas na mesma sessão de jogo — útil para quem quer confirmar com certeza antes de aplicar qualquer uma das soluções deste guia, em vez de aplicar todas ao mesmo tempo sem saber qual realmente ajudou.
Perguntas frequentes
Trocar de GPU resolve shader compilation stutter?
Raramente de forma significativa. Como o gargalo é a compilação em CPU, não a renderização em GPU, uma placa de vídeo mais rápida não acelera esse processo. Em alguns casos até expõe mais o problema, já que a GPU fica ociosa esperando a compilação terminar, tornando a pausa mais perceptível em comparação ao frame rate alto que o resto do jogo sustenta.
Por que o stutter volta depois de uma atualização do driver de vídeo?
Porque atualizações de driver frequentemente invalidam o cache de shaders existente (a nova versão do driver pode compilar shaders de forma ligeiramente diferente da anterior), forçando o sistema a recompilar do zero na próxima sessão de cada jogo — o mesmo efeito de “primeira vez” que acontece na instalação inicial.
Isso também acontece em consoles, ou é só problema de PC?
Também acontece em consoles, mas de forma mais controlada — como o hardware é fixo e conhecido, os estúdios podem pré-compilar shaders especificamente para aquele hardware durante o desenvolvimento. No PC, a variedade quase infinita de combinações de GPU, driver e configuração torna impraticável pré-compilar tudo antecipadamente para cada usuário, por isso o problema é mais visível nessa plataforma.
Fechar programas em segundo plano ajuda com esse tipo de stutter?
Ajuda pouco, e só de forma indireta. Como a compilação de shaders costuma usar poucas threads da CPU, liberar núcleos adicionais fechando outros programas raramente muda o tempo de compilação de forma perceptível. O ganho real vem das soluções específicas deste guia — pré-compilação, cache de shader preservado e, quando disponível, patches do próprio jogo — não da liberação geral de recursos do sistema.