No momento, você está visualizando NeuralScreen 2.1.7 Reduz Stutter do Frame Generation

NeuralScreen 2.1.7 Reduz Stutter do Frame Generation

  • Autor do post:
  • Última modificação do post:27 de setembro de 2026
  • Categoria do post:Notícias
  • Tempo de leitura:8 minutos de leitura

O NeuralScreen 2.1.7 corrige problemas importantes do Frame Generation e muda a forma como o programa decide quais imagens devem alimentar o DLSS-G. A atualização, publicada em 27 de setembro de 2026, impede que quadros sem conteúdo visual novo consumam avaliações completas do Frame Generation e também corrige o pacing baseado na taxa de atualização da tela. Nos testes do desenvolvedor, mover apenas o ponteiro sobre uma imagem parada fazia o processamento subir de 144 para 226 slots por segundo; agora, ele permanece em 144.

A versão também resolve duas regressões introduzidas na linha 2.1.5 e adiciona atalhos para controlar diretamente o número de passes do Neural Rendering. Portanto, embora seja classificada como um patch da série 2.1, a atualização altera tanto o comportamento temporal do Frame Generation quanto o controle do processamento neural.

NeuralScreen 2.1.7 e interface da edição NVIDIA

Interface oficial da edição NVIDIA do NeuralScreen. A captura serve como referência da interface do projeto e não representa isoladamente as medições da versão 2.1.7. Imagem: perseval-BLR/NeuralScreen.

NeuralScreen 2.1.7 deixa de gerar quadros para imagens repetidas

Uma das principais correções ataca um comportamento que aumentava desnecessariamente a carga do Frame Generation. Antes, cada frame produzido pelo loop do NeuralScreen entrava no FG como se representasse uma imagem real nova.

Entretanto, nem sempre havia pixels novos. Uma atualização do Desktop Duplication provocada apenas pelo movimento do ponteiro podia carregar exatamente a mesma imagem anterior. Da mesma forma, uma janela capturada que não tivesse redesenhado seu conteúdo podia retornar sem uma nova imagem útil.

Mesmo assim, o programa tratava esses eventos como novos frames. Consequentemente, cada um consumia um conjunto completo de avaliações do DLSS-G e ocupava um slot temporal que poderia interferir nos frames gerados a partir da atualização real.

Segundo o desenvolvedor, esse comportamento produzia um sintoma bastante perceptível: o vídeo podia apresentar stutter enquanto o usuário movimentava o mouse, ao mesmo tempo que o contador e a carga da GPU aumentavam.

O NeuralScreen 2.1.7 passa a reter esses frames quando não existe uma imagem realmente nova. Além disso, o Frame Generation agora distribui os quadros usando os timestamps da própria fonte, em vez de depender do momento em que o loop conseguiu processá-los.

Movimento do mouse fazia o FG subir de 144 para 226 slots

O desenvolvedor publicou uma medição direta para demonstrar a diferença. Ao mover apenas o ponteiro sobre uma imagem estática, a implementação anterior fazia o Frame Generation subir de 144 para 226 slots por segundo.

Depois da correção, a mesma situação permanece em 144 slots por segundo. Dessa forma, o simples movimento do cursor deixa de criar trabalho adicional como se a imagem capturada tivesse recebido uma atualização completa.

Esse resultado não deve ser interpretado como um benchmark de FPS de um jogo. A medição observa especificamente os slots processados pelo caminho de Frame Generation durante o cenário reproduzido pelo desenvolvedor.

O comportamento complementa mudanças anteriores do projeto. O Allves Games já detalhou como o NeuralScreen 2.1.4 corrigiu o caminho de sincronização do Frame Generation. A versão 2.1.7 avança sobre essa área, porém atua em problemas posteriores e independentes relacionados à seleção dos frames e ao pacing efetivo.

Configurações da edição NVIDIA do NeuralScreen com opções do programa

Tela de configurações da edição NVIDIA do NeuralScreen. A versão 2.1.7 também amplia os controles por teclado do processamento neural. Imagem: perseval-BLR/NeuralScreen.

Janela parada deixa de fazer o loop rodar centenas de vezes

O modo de captura de janela apresentava uma variação do mesmo problema. Quando uma janela não tinha conteúdo novo, a captura retornava imediatamente. Assim, uma janela completamente estática podia fazer o loop executar centenas de vezes por segundo sobre a mesma imagem.

Nessa situação, o Frame Generation parecia não produzir o resultado esperado porque o pipeline continuava recebendo repetições da mesma fonte.

A atualização faz a captura aguardar o próximo frame real da janela, aproximando seu comportamento daquele usado na captura do desktop.

O teste publicado pelo projeto mostra uma diferença expressiva. Em uma janela estática, o loop passou de 232 frames por segundo para 10 frames por segundo. Novamente, esse número descreve o comportamento interno da captura naquele teste, e não o desempenho de um jogo.

Frame Generation agora é realmente sincronizado pela tela

Outra correção importante envolve o mecanismo que deveria cadenciar a apresentação dos frames pelo display.

A linha anterior já utilizava um objeto de espera associado à latência do swap chain. Porém, o contador desse mecanismo acumulava uma ocorrência para cada apresentação e a apresentação normal não consumia essa fila.

Quando o Frame Generation começava, o objeto podia carregar aproximadamente 40 sinais pendentes. Consequentemente, as esperas do presenter retornavam imediatamente em vez de bloquear até o próximo intervalo apropriado da tela.

O log ainda indicava que o sistema estava sendo cadenciado pelo compositor, mas a espera efetiva podia permanecer em 0,00 ms.

O NeuralScreen 2.1.7 limpa esse contador antes de iniciar o presenter do FG. Assim, a espera passa a corresponder efetivamente ao ritmo de atualização do display.

Teste em 144 Hz reduz frames atrasados

O desenvolvedor mediu a mudança usando Frame Generation em 4x sobre uma tela de 144 Hz. Antes da correção, a espera anterior a cada apresentação permanecia em 0,00 ms.

Depois do ajuste, cada espera passou a corresponder a um vblank. Ao mesmo tempo, o número de frames descartados por chegarem atrasados caiu de aproximadamente 95 para cerca de 5 a cada dois segundos.

Esses números pertencem à configuração testada pelo autor e não devem ser generalizados para todas as GPUs, monitores ou cargas. Ainda assim, eles demonstram diretamente que o caminho anterior não estava obedecendo ao pacing indicado pelo próprio log.

Para quem utiliza o programa sobre jogos, emuladores ou vídeos, essa mudança é especialmente relevante porque o NeuralScreen funciona sobre a imagem capturada do Windows. O nosso guia do NeuralScreen explica o funcionamento da captura, Neural Rendering e Frame Generation, além das diferenças entre as edições NVIDIA e AMD.

Seleção de janelas no NeuralScreen NVIDIA para processamento de uma aplicação

Seleção de janelas na edição NVIDIA do NeuralScreen. A versão 2.1.7 corrige especificamente o comportamento da captura quando uma janela permanece sem novos frames. Imagem: perseval-BLR/NeuralScreen.

Duas regressões da versão 2.1.5 também foram corrigidas

A atualização resolve ainda dois problemas que apareceram depois das mudanças da versão 2.1.5.

O primeiro afetava telas estáticas. Um segundo inteiro sem receber um novo frame era interpretado como uma pausa da captura. Quando o usuário voltava a rolar uma página ou um vídeo começava novamente, o NeuralScreen reiniciava o histórico do Neural Rendering e do Frame Generation.

Esse reset podia provocar um hitch justamente no início do movimento. Agora, o programa só reinicia esse histórico quando a captura realmente perde sua fonte, como no fechamento ou reabertura da captura ou quando uma janela fica minimizada ou oculta.

A segunda regressão envolvia a reabertura de uma captura. Uma correção anterior descartava o primeiro frame de cada nova sessão. Entretanto, em uma tela parada, aquele primeiro frame podia ser justamente a única imagem disponível.

A versão 2.1.7 passa a descartar somente um primeiro frame que esteja realmente vazio. Além disso, a atualização corrige a troca a partir de um monitor desconectado quando ele correspondia à saída 0.

NeuralScreen 2.1.7 adiciona atalhos para os passes de NR

O patch também traz uma novidade diretamente relacionada ao Neural Rendering. Agora, Num+ e Num- aumentam ou reduzem a cascata entre 1 e 4 passes.

Os atalhos podem ser remapeados em Settings → Keys. Além disso, o aviso exibido pelo programa informa quantos passes realmente estão em execução.

Essa distinção importa porque a cascata depende do Boost. Uma imagem pequena demais para reduzir novamente a resolução de trabalho pode executar apenas um pass, mesmo que o usuário tenha solicitado uma quantidade maior.

Portanto, o novo controle não significa que quatro passes serão aplicados incondicionalmente a qualquer fonte. O programa continua respeitando as condições necessárias para construir a cascata.

O uso de múltiplas passadas pode aumentar consideravelmente o custo computacional. Assim, quantidade maior não deve ser interpretada automaticamente como melhor configuração para jogar. A utilidade depende da resolução, da carga da GPU, da imagem e do objetivo do teste.

O que realmente muda nesta atualização?

O principal delta da versão 2.1.7 está no tratamento temporal do Frame Generation. O programa passa a distinguir uma atualização real de imagem de eventos que apenas repetem pixels já processados.

Ao mesmo tempo, o presenter passa a consumir corretamente o ritmo imposto pelo display, em vez de encontrar sinais antigos acumulados no objeto de espera.

As duas mudanças atacam problemas diferentes, mas relacionados. A primeira evita avaliações desnecessárias do DLSS-G. Já a segunda procura entregar os quadros gerados no momento adequado.

As correções das regressões também reduzem resets desnecessários quando uma cena volta a se movimentar. Por fim, os atalhos Num+ e Num- tornam os testes de múltiplas passadas do Neural Rendering mais rápidos, sem exigir a alteração manual do controle a cada comparação.

Resultados ainda pertencem aos testes do desenvolvedor

As medições publicadas são úteis porque incluem cenários reproduzíveis e números de antes e depois. Entretanto, elas vêm dos testes do próprio projeto.

O release não publica uma bateria independente de benchmarks em diferentes placas GeForce, resoluções e monitores. Portanto, ainda não é possível afirmar qual será a redução de carga ou stutter em todas as configurações.

Também é importante separar Frame Generation de Neural Rendering. Embora ambos façam parte do NeuralScreen, o DLSS-G gera frames intermediários, enquanto o Neural Rendering executa outro tipo de processamento sobre a imagem. A versão 2.1.7 mexe nos dois caminhos, porém por razões diferentes.

O projeto continua exigindo driver NVIDIA atualizado e permanece uma ferramenta comunitária, sem vínculo oficial com a NVIDIA.

Fontes: NeuralScreen v2.1.7 — release oficial | NeuralScreen — repositório oficial da edição NVIDIA.