O NeuralScreen 2.1.4 corrige o Frame Generation ao resolver um problema no pacing dos quadros interpolados. A atualização, publicada em 24 de setembro de 2026, faz o apresentador do programa sincronizar os frames gerados com a disponibilidade real do back buffer do compositor, em vez de depender do mecanismo de temporização de fallback usado nas versões anteriores.
A mudança é importante porque o NeuralScreen já tentava utilizar essa sincronização, mas o caminho nunca funcionou como pretendido. O programa chamava SetMaximumFrameLatency(1) e GetFrameLatencyWaitableObject(), porém criava o swap chain sem a flag necessária para que essas funções operassem corretamente.
A versão 2.1.4 adiciona finalmente DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT. Com isso, uma sessão de Frame Generation reduz a latência máxima do swap chain de 3 para 1 e restaura o valor 3 quando o FG termina.
Interface oficial do NeuralScreen 2.1.4. O painel permite ativar Frame Generation em multiplicadores de 2x, 3x ou 4x. Imagem: perseval-BLR/NeuralScreen.
NeuralScreen 2.1.4 corrige o pacing do Frame Generation
O desenvolvedor detalhou a correção nas notas oficiais da versão 2.1.4.
O objetivo do presenter do Frame Generation sempre foi esperar o compositor liberar o back buffer anterior antes de apresentar o próximo frame. Dessa forma, o sistema poderia alinhar melhor a entrega dos quadros gerados à apresentação real.
Entretanto, esse caminho não funcionava.
A causa estava na criação do swap chain. O NeuralScreen utilizava as funções destinadas ao controle de frame latency, mas não habilitava DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT.
Sem essa flag, o waitable object necessário para a sincronização não oferecia o comportamento que o presenter esperava. Portanto, o código acabava recorrendo a um caminho alternativo baseado em temporização.
A versão 2.1.4 corrige exatamente essa etapa.
| Situação | Antes | NeuralScreen 2.1.4 |
|---|---|---|
| Flag do swap chain | Ausente | FRAME_LATENCY_WAITABLE_OBJECT |
| FG ativo | Fallback de pacing | Latência máxima 1 |
| FG desligado | — | Latência volta para 3 |
O desenvolvedor confirmou o novo caminho durante uma execução real. O log passou a registrar a mensagem:
[fg] the presenter is paced by the compositor (latency 1)
Assim, a correção não existe apenas no código. O projeto também confirmou que o presenter realmente entra no modo sincronizado durante uma sessão de Frame Generation.
O que muda na prática durante o movimento?
O principal efeito esperado aparece na regularidade com que o NeuralScreen apresenta os frames interpolados.
Um contador de FPS pode indicar uma taxa elevada e, mesmo assim, o movimento parecer irregular. Isso acontece porque quantidade de frames e regularidade de apresentação são métricas diferentes.
Por exemplo, 120 quadros distribuídos irregularmente durante um segundo não produzem necessariamente a mesma sensação visual de 120 quadros entregues em intervalos consistentes.
Antes da 2.1.4, o presenter do NeuralScreen não utilizava a sincronização com o compositor da maneira planejada. Agora, ele pode esperar pela disponibilidade do buffer antes de apresentar o próximo resultado.
Por isso, usuários que perceberam pacing irregular, movimento pouco uniforme ou uma sensação de que os frames gerados não acompanhavam corretamente a tela têm um motivo concreto para repetir os testes.
Entretanto, a atualização não garante que qualquer problema visual de Frame Generation desapareça.
A correção não elimina os artefatos do Frame Generation
O NeuralScreen trabalha com Frame Generation em nível de tela, sem receber todas as informações internas que uma integração nativa dentro de um jogo pode fornecer.
Segundo a documentação técnica do projeto, o sistema utiliza profundidade plana e estima o movimento a partir das imagens.
Consequentemente, elementos de interface, textos, partículas, objetos que surgem rapidamente e movimentos complexos ainda podem apresentar distorções.
A versão 2.1.4 não altera esse algoritmo de interpolação.
A atualização corrige quando o NeuralScreen apresenta os frames, e não como a rede cria cada frame intermediário.
Portanto, um movimento que antes parecia irregular por causa do pacing pode melhorar. Já um objeto deformado pela estimativa de movimento ainda pode continuar deformado.
Por que o NeuralScreen não deixa a latência em 1 o tempo inteiro?
O desenvolvedor já havia experimentado uma abordagem mais simples: criar o swap chain e manter a latência em 1 permanentemente.
Porém, esse caminho provocou flicker no Neural Rendering convencional.
Por isso, a implementação final adota um comportamento dinâmico.
O swap chain começa com latência máxima 3. Quando o usuário ativa Frame Generation, o NeuralScreen muda o valor para 1. Depois, quando o FG termina, o programa restaura 3.
Assim, o projeto tenta obter o pacing mais adequado ao FG sem alterar permanentemente o comportamento do caminho tradicional de Neural Rendering.
HDR não deve remover silenciosamente a nova sincronização
A atualização também leva em conta mudanças no swap chain durante a execução.
Quando o programa chama ResizeBuffers, ele reutiliza as próprias flags do swap chain. Dessa forma, DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT continua presente depois da recriação dos buffers.
Isso importa especialmente quando o usuário alterna para uma configuração HDR.
Sem esse cuidado, uma troca de modo poderia recriar os buffers sem a flag e fazer o presenter voltar silenciosamente ao comportamento antigo.
A versão 2.1.4 evita esse cenário.
As configurações do NeuralScreen 2.1.4 incluem captura HDR experimental e opções de estimativa de movimento. Imagem oficial: perseval-BLR/NeuralScreen.
NeuralScreen 2.1.4 também corrige imagem invertida com HDR e NR
A atualização resolve outro defeito relacionado ao HDR.
Em determinadas configurações de display ou captura invertida, o shader de captura aplicava a transformação rotate180 aos proxies SDR.
Entretanto, a composição HDR lia o frame nativo sem aplicar a mesma orientação.
Como resultado, o usuário podia encontrar uma imagem duplicada e invertida quando ativava Neural Rendering.
A versão 2.1.4 passa a aplicar a mesma orientação ao frame usado pela composição HDR. Assim, os dois caminhos voltam a trabalhar com a imagem na mesma posição.
DRED agora pode ajudar a investigar crashes da GPU
Outra correção técnica envolve o DRED, sigla para Device Removed Extended Data.
O Windows oferece esse mecanismo para registrar informações adicionais quando o Direct3D perde o dispositivo gráfico, situação que pode ocorrer durante um crash do driver ou da GPU.
Antes da atualização, o NeuralScreen tentava habilitar os breadcrumbs de DRED através do device D3D12 que já existia.
Esse caminho não funcionava. Por isso, o log retornava 0x80004002 e informava que o recurso estava indisponível.
Agora, o programa obtém a interface correta através de D3D12GetDebugInterface antes de chamar D3D12CreateDevice.
Na prática, isso não aumenta FPS nem melhora a qualidade de imagem. Contudo, a mudança pode produzir informações muito mais úteis quando NR ou FG provocam um device removed.
Assim, um relatório de erro passa a ter maior chance de apontar onde a GPU estava trabalhando quando ocorreu a falha.
Versão também corrige validação de DLLs NVIDIA legítimas
O NeuralScreen verifica a procedência de determinados runtimes antes de carregá-los.
Entretanto, duas cópias legítimas de sl.dlss.dll apresentavam certificados que já haviam expirado. O programa verificava a cadeia usando a data atual e acabava rejeitando essas DLLs como se elas não tivessem uma assinatura válida da NVIDIA.
A versão 2.1.4 passa a considerar corretamente a assinatura com timestamp.
Isso significa que uma DLL assinada de forma válida quando a NVIDIA a publicou não deixa de ser reconhecida simplesmente porque o certificado utilizado naquela assinatura expirou posteriormente.
Portanto, a mudança melhora a verificação de procedência sem simplesmente desativar a validação.
Correções também atingem o modo de janela
O release inclui ainda ajustes no comportamento do overlay quando o NeuralScreen captura apenas uma janela.
Em uma das situações corrigidas, uma imagem antiga e maior podia permanecer visível além dos limites da janela depois de uma mudança de tamanho.
Agora, o programa esconde temporariamente essa imagem até concluir o redimensionamento.
Além disso, uma incompatibilidade de tamanho podia congelar o último frame e depois fazer o overlay reaparecer continuamente. A atualização também corrige esse caminho.
O NeuralScreen pode processar a tela inteira ou apenas uma janela selecionada pelo usuário. Imagem oficial da versão 2.1.4: perseval-BLR/NeuralScreen.
A correção vale para jogos e emuladores?
Sim. O Frame Generation do NeuralScreen atua sobre a imagem capturada pelo programa, e não exige uma integração específica dentro do jogo ou emulador.
Por isso, a correção do presenter se aplica ao caminho geral de Frame Generation no Windows.
O usuário pode capturar a tela inteira ou selecionar uma janela específica. Portanto, jogos, vídeos, aplicativos e emuladores podem passar pelo mesmo pipeline.
Entretanto, o resultado visual continua dependendo do conteúdo capturado.
Um jogo com movimento previsível pode gerar resultados diferentes de um emulador com HUD, texto, mudanças rápidas de câmera ou elementos 2D sobrepostos.
Além disso, o NeuralScreen ainda recomenda evitar seu uso em jogos competitivos com sistemas anti-cheat.
Vale repetir os testes feitos no NeuralScreen 2.1.3?
Sim. A mudança interfere justamente na apresentação dos frames produzidos pelo Frame Generation.
Por isso, uma comparação direta entre 2.1.3 e 2.1.4 pode mostrar diferenças que um contador de FPS sozinho não revela.
Para um teste A/B mais confiável, o ideal é manter:
- o mesmo jogo ou emulador;
- a mesma cena;
- a mesma resolução;
- o mesmo FPS-base;
- o mesmo multiplicador de Frame Generation;
- a mesma configuração de Neural Rendering;
- o mesmo Boost;
- o mesmo limite de frames;
- os mesmos movimentos de câmera.
Depois disso, vale observar principalmente a regularidade visual durante panorâmicas, movimentos laterais e rotações de câmera.
Também faz sentido registrar frametimes, caso a ferramenta utilizada consiga medir a apresentação final de forma adequada.
Por outro lado, uma simples comparação de “FPS antes e depois” provavelmente não mostrará o principal benefício dessa correção.
A versão 2.1.4 não foi anunciada como uma atualização destinada a aumentar a quantidade de frames gerados. O objetivo é apresentar esses frames no momento correto.
A versão AMD ainda não foi validada em uma Radeon real
O release volta a mencionar o projeto separado NeuralScreen-AMD.
Entretanto, o próprio desenvolvedor continua procurando usuários para realizar testes em hardware real.
A documentação afirma que essa variante ainda não foi executada com sucesso em uma Radeon real.
Além disso, o Frame Generation da build AMD não funciona atualmente, pois esse caminho depende do runtime de optical flow utilizado pela implementação NVIDIA.
Portanto, as correções de Frame Generation da versão 2.1.4 não devem ser interpretadas como confirmação de FG funcionando em placas Radeon.
O que os testes oficiais realmente confirmam?
O release oficial informa que o projeto adicionou ou ampliou testes para conversão de orientação, rotação de logs, comunicação entre instâncias, reconstrução do tema e segurança do worker.
Segundo os desenvolvedores, cada um desses testes falhava sobre o código da versão 2.1.3 antes das respectivas correções.
Além disso, o desenvolvedor confirmou em execução real que o presenter entra no novo caminho sincronizado com o compositor e registra latência 1 durante o Frame Generation.
Por enquanto, porém, ainda não há um benchmark independente mostrando quanto essa alteração modifica frametimes, latência ou suavidade em um jogo ou emulador específico.
Assim, a evidência disponível confirma a correção técnica e o funcionamento do novo caminho. A magnitude da diferença visual ainda precisa de testes comparativos em diferentes configurações.
O que muda de fato no NeuralScreen 2.1.4?
A principal novidade não está no número de frames que o NeuralScreen consegue fabricar.
O avanço está na forma como esses frames chegam à tela.
Nas versões anteriores, o programa possuía código para sincronizar o presenter com o compositor, mas o swap chain não tinha a flag necessária para fazer esse mecanismo funcionar.
A versão 2.1.4 finalmente conecta as duas partes.
Agora, quando Frame Generation entra em funcionamento, o swap chain passa para latência máxima 1 e o presenter espera a liberação do back buffer. Quando o usuário desativa FG, o sistema retorna a latência para 3 e preserva o comportamento do Neural Rendering convencional.
Por isso, a atualização merece atenção principalmente de quem já havia experimentado Frame Generation e percebeu movimento irregular mesmo com um contador de FPS elevado.
Ao mesmo tempo, é importante manter a expectativa correta: o NeuralScreen 2.1.4 corrige o pacing da apresentação, mas não modifica a própria interpolação responsável por possíveis deformações nos frames gerados.
Fontes: NeuralScreen — release oficial v2.1.4 | NeuralScreen — repositório e documentação oficial | NeuralScreen — documentação técnica | NeuralScreen-AMD — repositório oficial.
