O DLSS5-Feeder 1.17.0-beta.3 corrige uma incompatibilidade importante entre versões antigas do add-on RenoDX DLSS 5 e drivers NVIDIA recentes. O desenvolvedor publicou a nova beta em 25 de setembro de 2026, após confirmar que o RenoDX v4.7 podia deixar de criar e executar o Feature 18 em drivers da linha 616.64 ou superior, mesmo quando o restante da instalação aparentemente funcionava.

Além disso, a atualização leva o Output Stabiliser experimental para todos os caminhos de 64 bits. O recurso, que havia estreado no helper destinado a jogos 32-bit, agora funciona nos transportes Direct3D 12, Direct3D 11, Vulkan e OpenGL.

O release também muda o instalador automático. Em vez de manter uma versão antiga do RenoDX DLSS 5 presa no cache, o script agora consulta o repositório RHI para localizar o add-on e o modelo neural mais recentes disponíveis, além de separar o cache por release.

DLSS5-Feeder 1.17.0-beta.3 corrige problema com drivers NVIDIA recentes

O desenvolvedor detalhou as mudanças no release oficial do DLSS5-Feeder no GitHub.

O problema mais importante envolve o add-on RenoDX DLSS 5. Instalações anteriores utilizavam com frequência a versão v4.7, inclusive através de versões anteriores do script de instalação automática.

Entretanto, essa combinação começou a falhar com drivers NVIDIA mais recentes.

Segundo os testes publicados pelo projeto, o RenoDX v4.7 obteve 0 avaliações bem-sucedidas em 300 tentativas no driver NVIDIA 617.14.

Já versões mais novas do add-on completaram todas as avaliações do self-test.

O teste utilizou uma GeForce RTX 5090 e o driver 617.14. Portanto, esses números demonstram a diferença dentro dessa configuração específica e não constituem um benchmark geral de desempenho.

O resultado mostra, porém, que as versões modernas do RenoDX conseguiram criar e avaliar o Feature 18 onde o v4.7 falhou completamente.

O que é o Feature 18 e por que uma instalação podia parecer normal?

O DLSS5-Feeder cria uma chamada de DLSS que o jogo originalmente não faria. Dessa forma, o add-on de Neural Rendering consegue interceptar essa avaliação e inserir o processamento neural.

O projeto identifica o recurso de Neural Rendering como Feature 18.

Por isso, uma instalação pode carregar ReShade, compilar os shaders e até executar o DLSS convencional sem que o Neural Rendering realmente funcione.

Esse cenário ajuda a explicar casos em que o usuário atualizava o driver e percebia pouca ou nenhuma transformação visual, embora os arquivos principais ainda aparecessem carregados.

Na combinação problemática, o DLSS podia continuar fornecendo sua etapa de antialiasing enquanto a criação do Feature 18 falhava.

Assim, observar somente a presença do ReShade ou do add-on não garante que a rede neural esteja realmente executando.

Feeder também confundia versões modernas do RenoDX com a antiga v4.7

A incompatibilidade revelou outro problema.

As versões recentes do RenoDX DLSS 5 mantêm alguns marcadores internos que também existem no v4.7. Como consequência, o DLSS5-Feeder podia identificar uma versão moderna como se ela fosse a antiga.

Isso gerava avisos incorretos sobre incompatibilidade.

A beta.3 muda o sistema de identificação. Agora, o programa procura o version banner real do add-on e utiliza a data de compilação como alternativa quando o banner não existe.

Além disso, os dois binários 64-bit passam a reconhecer corretamente versões com sufixos de pré-lançamento.

Por exemplo, o sistema agora consegue interpretar v7.0.0-rc8 sem reduzir essa identificação a uma versão genérica ou antiga.

Driver 616.64 passa a ser um ponto importante para o RenoDX antigo

A documentação atualizada destaca uma mudança prática para quem utiliza drivers recentes.

O instalador anterior podia baixar ou reutilizar o RenoDX DLSS 5 v4.70. Contudo, o projeto registra que essa versão falha no caminho testado a partir do driver 616.64.

Por isso, a recomendação já não consiste apenas em atualizar o DLSS5-Feeder.

Também é importante verificar qual versão do consumidor neural RenoDX está instalada.

Isso se torna especialmente relevante em instalações antigas que funcionaram durante semanas e começaram a falhar depois de uma atualização do driver NVIDIA.

Instalador passa a buscar o RenoDX e o modelo neural mais recentes

A beta.3 também modifica o script Install-DLSS5Feeder.ps1.

Anteriormente, o instalador automático trabalhava com uma versão fixa do RenoDX DLSS 5. Além disso, o sistema de cache podia reutilizar indefinidamente a primeira cópia que havia baixado.

Assim, um usuário podia executar novamente o instalador meses depois e continuar recebendo os mesmos arquivos antigos armazenados localmente.

A nova implementação consulta o repositório RHI a cada execução para localizar os releases mais recentes de renodx-dlss5-* e dlssnr-*.

Durante os testes dessa versão, o script encontrou RenoDX 7.0.0-rc8 e o modelo 310.8.Lecram.

Além disso, o cache agora separa os arquivos por release.

Quando não existe conexão, o instalador procura a versão mais recente que já esteja armazenada no cache.

O desenvolvedor testou especificamente a etapa de download contra o repositório RHI ao vivo, depois repetiu o processo usando o cache e finalmente executou essa etapa offline.

Entretanto, as notas da beta.3 deixam uma ressalva: o desenvolvedor ainda não executou um ciclo completo do instalador do início ao fim nessa release.

Output Stabiliser chega aos jogos 64-bit

A segunda grande novidade envolve o estabilizador temporal experimental.

Na beta.2, esse recurso apareceu primeiro no helper utilizado por jogos 32-bit.

Agora, a beta.3 porta o mesmo compute pass para todos os transportes de 64 bits suportados pelo add-on:

• Direct3D 12: utiliza o próprio device do jogo;
• Direct3D 11;
• Vulkan;
• OpenGL.

O sistema executa um compute pass depois da avaliação neural.

Quando a imagem original permanece praticamente igual entre dois momentos, o estabilizador pode conservar parte da interpretação neural anterior. Por outro lado, quando a entrada muda acima do limite definido, ele acompanha a nova saída produzida pelo modelo.

O objetivo é reduzir mudanças temporais indesejadas em regiões que deveriam permanecer visualmente estáveis.

Hold strength e Change tolerance controlam o estabilizador

A interface mantém dois controles principais.

Hold strength define quanto da interpretação anterior o sistema tenta preservar. O valor zero mantém o recurso desligado, que continua sendo o comportamento padrão.

Já Change tolerance determina quanta diferença precisa surgir na imagem original antes que o estabilizador abandone a saída retida e aceite completamente a nova interpretação neural.

Assim, o usuário pode ajustar o equilíbrio entre estabilidade temporal e capacidade de acompanhar mudanças da cena.

Entretanto, o recurso continua experimental. Uma retenção excessiva pode criar seus próprios problemas em cenas com movimento ou mudanças rápidas.

Estabilizador 64-bit ainda não recebeu validação em gameplay

Esse ponto é importante para interpretar corretamente a atualização.

O projeto confirma que o estabilizador compila nos transportes de 64 bits e que a implementação está presente na beta.3.

Porém, o desenvolvedor afirma que a versão 64-bit do Output Stabiliser ainda não foi executada dentro de um jogo nesta release.

O teste prático publicado anteriormente continua sendo o da implementação do helper de 32 bits.

Portanto, ainda não existe base para afirmar que o recurso reduz determinado percentual de flicker, melhora frametimes ou resolve instabilidades temporais específicas em jogos de 64 bits.

Também não há teste novo e específico em PCSX2, RPCS3, Dolphin ou outros emuladores.

A mudança permite testar o estabilizador em mais jogos e emuladores

Apesar da ausência de uma validação específica, o suporte de 64 bits amplia bastante o campo de testes.

Muitos jogos modernos utilizam executáveis 64-bit. Além disso, emuladores como PCSX2, RPCS3 e Dolphin também possuem builds modernas de 64 bits.

Por isso, a nova implementação cria a possibilidade técnica de testar o estabilizador em pipelines D3D11, D3D12 e Vulkan usados por esses programas.

Isso não significa que o desenvolvedor tenha confirmado compatibilidade ou benefício em cada emulador.

Na prática, a beta.3 apenas remove a limitação que mantinha o estabilizador preso ao caminho especial de jogos 32-bit.

RTX 20, 30 e 40 continuam exigindo atenção especial

A atualização do RenoDX não resolve outra limitação importante do Neural Rendering.

Segundo as notas oficiais, a DLL NVIDIA assinada nvngx_dlssnr.dll 310.8.0 cria o recurso neural no cenário documentado apenas em GPUs GeForce RTX Série 50.

A variante modificada 310.8.Lecram, que o instalador passou a localizar no repositório RHI, também foi validada pelo desenvolvedor somente em uma RTX Série 50.

Em RTX 20, RTX 30 ou RTX 40, o DLSS convencional pode inicializar enquanto o Neural Rendering falha.

Nesse caso, o log pode apresentar:

feature 18 create failed with 0xbad00001

Assim, trocar apenas o RenoDX v4.7 por uma versão nova não transforma automaticamente o runtime neural destinado à RTX Série 50 em uma implementação funcional nas gerações anteriores.

O projeto orienta usuários dessas placas a utilizar uma versão modificada de nvngx_dlssnr.dll preparada especificamente para a arquitetura correspondente.

RTX 5090 completou 300 avaliações com diferentes combinações

A validação principal da beta.3 utilizou uma RTX 5090 com driver NVIDIA 617.14.

O helper completou 300 de 300 avaliações com Feature 18 usando RenoDX 7.0.0-rc8 e o modelo NVIDIA assinado.

Além disso, a mesma versão do RenoDX completou 300 de 300 avaliações com a variante 310.8.Lecram.

O RenoDX v8.0.1 também completou as 300 avaliações.

Separadamente, a documentação da versão confirma que RenoDX v6.1.0 também passou pelo self-test de 300 avaliações.

Já o antigo v4.7 permaneceu em zero de 300 no mesmo driver.

Esses resultados fornecem evidência forte para a correção de compatibilidade. Porém, eles medem criação e avaliação do recurso neural no self-test, e não FPS ou qualidade visual dentro de um jogo.

Como verificar se o Neural Rendering realmente está funcionando?

A nova versão torna essa distinção ainda mais importante.

O próprio projeto oferece um self-test no helper. Quando a configuração funciona corretamente, ele pode completar as 300 avaliações com o Feature 18 criado.

Além disso, o log do DLSS5-Feeder registra as etapas de inicialização e execução.

Isso ajuda a separar três cenários diferentes:

• ReShade carregou, mas o Feeder não iniciou corretamente;
• DLSS funcionou, mas o Feature 18 não foi criado;
• DLSS e Neural Rendering estão sendo realmente avaliados.

Essa distinção é especialmente útil depois de uma atualização de driver, pois a interface pode parecer normal mesmo quando a etapa neural falha.

DLSS5-Feeder continua atendendo jogos sem DLSS próprio

O objetivo central do projeto permanece o mesmo.

O add-on de DLSS 5 normalmente espera encontrar chamadas de DLSS feitas pelo próprio jogo. Quando um título não possui DLSS, essas chamadas simplesmente não existem.

O DLSS5-Feeder cria esse contrato artificialmente a partir do frame, do depth buffer e dos vetores de movimento disponíveis através do ReShade.

Em seguida, ele executa uma avaliação DLAA real. O consumidor neural intercepta essa avaliação e insere o Neural Rendering.

Por isso, o projeto consegue levar esse pipeline a jogos D3D11, D3D12, Vulkan e OpenGL que originalmente não implementam DLSS.

Os caminhos para títulos 32-bit utilizam um helper de 64 bits, já que os componentes NGX necessários não possuem uma implementação de 32 bits.

Nem todo jogo 64-bit precisa mais do DLSS5-Feeder

A documentação atual também traz uma distinção importante para novas instalações.

Em determinados jogos 64-bit DirectX 9, 11 ou 12 que já fazem suas próprias chamadas de DLSS, existe agora uma rota mais simples através do add-on renodx-dlss.

Nesses casos, o próprio add-on pode aproveitar as chamadas existentes e o DLSS5-Feeder pode se tornar desnecessário.

Entretanto, o Feeder continua relevante quando o jogo não possui DLSS próprio.

Além disso, o projeto permanece necessário em casos como jogos 32-bit, Vulkan e determinadas configurações de DirectX 9 que dependem do contrato temporal criado pelo ReShade.

Arquivo oficial possui SHA-256 publicado pelo desenvolvedor

O projeto também reforçou seus alertas contra cópias falsas.

Segundo o desenvolvedor, a única fonte oficial dos pacotes do DLSS5-Feeder continua sendo a página de releases do próprio GitHub.

Para a versão 1.17.0-beta.3, o SHA-256 publicado para o ZIP oficial é:

7DB0D8C2B29DE702DEAAFCFEA9112DC15A35D62BB15E6FE0C982C150EF8D2392

O repositório também alerta para sites maliciosos e cópias de aparência semelhante.

Além disso, é importante diferenciar o pacote oficial do script de instalação automática. O projeto possui um script PowerShell de instalação em um comando, mas não distribui um instalador executável independente.

Vale testar a DLSS5-Feeder 1.17.0-beta.3?

Para quem já utiliza DLSS5-Feeder, especialmente após atualizar o driver NVIDIA, a beta.3 traz mudanças diretamente relacionadas à confiabilidade do Neural Rendering.

O teste com o driver 617.14 mostra uma diferença clara entre o RenoDX v4.7 e as versões modernas.

Assim, usuários que percebem DLSS funcionando sem uma transformação neural visível têm um motivo concreto para revisar a versão do add-on.

Já o Output Stabiliser 64-bit merece uma avaliação mais cautelosa.

A implementação agora cobre D3D12, D3D11, Vulkan e OpenGL, mas ainda não recebeu validação publicada dentro de um jogo de 64 bits nessa release.

Portanto, ele funciona melhor como recurso experimental para testes do que como uma correção comprovada para flicker ou instabilidade temporal.

O que a beta.3 muda de fato?

A principal correção resolve uma incompatibilidade concreta entre o RenoDX DLSS 5 antigo e drivers NVIDIA recentes.

Além disso, o Feeder agora identifica corretamente as versões novas do add-on e evita confundi-las com o v4.7.

O instalador também deixa de depender de um RenoDX fixo e passa a procurar as versões mais recentes no repositório RHI, com um cache separado por release.

Enquanto isso, o Output Stabiliser deixa de ser exclusivo do caminho 32-bit e passa a existir nos quatro transportes de 64 bits.

O resultado mais sólido da atualização está no self-test: no driver 617.14 e em uma RTX 5090, as versões RenoDX 6.1, 7.0.0-rc8 e 8.0.1 conseguiram criar e avaliar o Neural Rendering, enquanto o v4.7 falhou.

Já os ganhos visuais ou temporais do novo estabilizador em jogos e emuladores ainda dependem de testes práticos.

Fontes: DLSS5-Feeder — releases oficiais no GitHub | DLSS5-Feeder — repositório e documentação oficial | NewReleases — changelog espelhado da v1.17.0-beta.3 | DLSS 5 Neural Remaster — exemplo independente utilizando DLSS5-Feeder.