O DPRecomp 2.0.3 corrige crash GPU lost no novo renderer DirectX 12 nativo de Deadly Premonition. A atualização, publicada em 25 de setembro de 2026, resolve uma falha estrutural que podia fazer o Windows reiniciar a GPU depois de alguns minutos de gameplay, durante a exploração de determinadas áreas ou ao fechar o menu de pausa.
O problema estava no gerenciamento do tempo de vida dos recursos gráficos. Em algumas situações, o jogo liberava os dados de um modelo e o renderer destruía imediatamente sua cópia na GPU. Entretanto, como a placa de vídeo trabalha de forma assíncrona, ela ainda podia estar utilizando aquele recurso para terminar de desenhar um frame anterior.
Assim, a GPU acabava tentando acessar uma região de memória que já havia sido descartada. O Windows interpretava a situação como uma falha do dispositivo gráfico, reiniciava a GPU e o DPRecomp encerrava com a mensagem “GPU lost”.
DPRecomp 2.0.3 corrige a causa do “GPU lost”
As notas oficiais da versão 2.0.3 detalham exatamente o que acontecia.
Deadly Premonition libera dados de modelos entre frames quando precisa carregar novas partes do mapa. Isso pode ocorrer enquanto York dirige pelas estradas, circula pelo hotel, entra em prédios ou simplesmente fecha o menu de pausa.
O novo renderer DirectX 12 mantinha sua própria representação desses recursos na placa de vídeo. Porém, quando o jogo deixava de utilizar determinado modelo, a implementação podia interpretar isso como autorização para destruir também o recurso correspondente na GPU.
O problema é que a CPU e a GPU não terminam seus trabalhos ao mesmo tempo.
Enquanto a CPU já estava preparando o próximo frame e considerava determinado modelo desnecessário, a GPU ainda podia estar desenhando o frame anterior com aquele mesmo recurso.
O fluxo que causava o crash pode ser resumido assim:
Jogo libera o modelo → renderer destrói o recurso na GPU → GPU ainda usa o recurso no frame anterior → memória já não existe → Windows reinicia a GPU → “GPU lost”.
A versão 2.0.3 muda esse comportamento. Agora, quando um recurso deixa de ser utilizado pelo jogo, o renderer o mantém vivo até que a placa de vídeo tenha terminado todos os frames que ainda dependem dele.
Deadly Premonition executado pelo novo renderer DirectX 12 nativo do DPRecomp em resolução interna 2×. A delegacia foi uma das áreas utilizadas pelos desenvolvedores durante os testes. Imagem oficial: Little Bit/DPRecomp.
O crash aparecia durante exploração, loading e menu de pausa
A falha não estava vinculada a uma única cena específica.
Segundo o desenvolvedor, Deadly Premonition libera modelos com frequência enquanto o jogador atravessa Greenvale. Isso ocorre porque novas partes do mapa entram e saem da memória conforme a posição de York.
As notas da atualização citam explicitamente situações nas estradas, no hotel, na entrada de prédios e depois do fechamento do menu de pausa.
Portanto, um usuário podia ativar o renderer nativo, jogar normalmente por alguns minutos e acreditar que tudo estava funcionando corretamente. O crash aparecia somente quando uma combinação específica de liberação de recurso e trabalho ainda pendente na GPU acontecia.
Esse comportamento também explica por que o erro surgiu com mais clareza depois que usuários começaram a realizar sessões mais longas com a série 2.0.
Versão 2.0.3 também reforça as threads de loading
A correção não se limita a adiar a destruição da cópia existente na VRAM.
O desenvolvedor reforçou a mesma área do renderer para evitar que objetos liberados pelas threads responsáveis por loading sejam desmontados enquanto uma operação gráfica potencialmente relacionada ainda está em andamento.
A partir da 2.0.3, esses objetos são desmontados apenas entre frames.
Isso reduz a possibilidade de mudanças perigosas na estrutura dos recursos enquanto o renderer está preparando ou executando trabalho gráfico.
Além disso, sessões prolongadas receberam outra correção. O renderer não deve mais correr o risco de esgotar seus slots internos destinados aos render targets ao longo do tempo.
Consequentemente, a versão atua tanto sobre o crash já identificado quanto sobre uma segunda condição que poderia afetar a estabilidade depois de sessões maiores.
Nova instrumentação identifica o recurso envolvido se o erro voltar
O projeto também manteve e ampliou o sistema de diagnóstico introduzido pouco antes.
Se outro “GPU lost” acontecer na versão 2.0.3, a mensagem e o log passam a indicar qual recurso a placa de vídeo estava tentando acessar no momento da falha.
Isso não significa que os desenvolvedores garantam que toda possível causa de perda de dispositivo foi eliminada.
Na verdade, eles continuam pedindo que usuários enviem logs caso o problema volte a aparecer.
A diferença é que um eventual segundo bug nessa área deverá deixar informações muito mais específicas para investigação.
DPRecomp 2.0.2 foi a etapa que ajudou a encontrar o problema
A versão 2.0.3 chegou poucas horas depois da 2.0.2, e as duas atualizações estão diretamente relacionadas.
Na 2.0.2, o projeto ainda não havia identificado a causa do “GPU lost”. Entretanto, passou a detectar quando a GPU deixava de responder, fechar o jogo de forma controlada e registrar o trabalho que a placa estava executando naquele momento.
Os logs enviados pelos testadores permitiram rastrear o erro até o gerenciamento do tempo de vida dos recursos.
Portanto, a 2.0.2 forneceu a instrumentação necessária e a 2.0.3 implementou a correção estrutural.
DPRecomp transforma a versão de Xbox 360 de Deadly Premonition em um port nativo para Windows por recompilação estática. Imagem oficial: Little Bit/DPRecomp.
Versão 2.0.2 também corrigiu uma tela preta no renderer nativo
A atualização anterior resolveu outro problema que podia ser confundido com uma falha do novo renderer.
O atualizador integrado ao launcher não estava copiando o arquivo de shaders necessário ao caminho DirectX 12 nativo.
Como resultado, uma instalação atualizada pelo próprio launcher podia iniciar o jogo com a tela completamente preta.
Em outros casos, o sistema continuava utilizando um arquivo de shaders pertencente a uma versão anterior.
Na 2.0.2, o arquivo entrou corretamente no fluxo de atualização.
Além disso, caso o shader necessário esteja totalmente ausente, o DPRecomp agora retorna ao renderer anterior em vez de simplesmente apresentar uma tela preta.
O que mudou entre DPRecomp 2.0, 2.0.2 e 2.0.3?
| Versão | Mudança principal |
|---|---|
| 2.0 | Renderer DirectX 12 nativo chega a um estágio considerado adequado para testes públicos e permanece opcional. |
| 2.0.2 | Corrige tela preta causada pelo atualizador e adiciona diagnóstico mais detalhado quando a GPU deixa de responder. |
| 2.0.3 | Corrige a causa conhecida dos crashes “GPU lost”, reforça o lifetime dos recursos e evita esgotamento dos slots de render targets em sessões longas. |
A sequência mostra como o renderer está avançando através de testes reais.
A versão 2.0 tornou o novo caminho utilizável. A 2.0.2 melhorou a distribuição e a capacidade de diagnosticar problemas. Já a 2.0.3 corrige um dos erros mais graves encontrados depois que jogadores começaram a utilizá-lo por períodos maiores.
O novo renderer DirectX 12 é diferente do caminho gráfico anterior
Deadly Premonition Recompilation utiliza recompilação estática para transformar as instruções PowerPC da CPU Xenon do Xbox 360 em código x86-64 executável no Windows.
Portanto, o projeto não executa o jogo dentro de uma CPU virtual do Xbox 360 em tempo real.
Entretanto, historicamente a parte gráfica ainda utilizava a infraestrutura derivada do ReXGlue para traduzir o comportamento da GPU Xenos do console para DirectX 12.
Esse é o caminho que o projeto chama atualmente de renderer emulado.
O novo renderer introduzido e aprimorado na série 2.0 segue uma estratégia diferente. O jogo pode ser desenhado diretamente através de um backend DirectX 12 criado especificamente para o port, em vez de depender da reprodução do caminho gráfico do Xbox 360.
Por isso, corrigir lifetime, sincronização e gerenciamento de recursos não é apenas uma correção de um crash isolado. Esses componentes são fundamentais para que um renderer nativo consiga substituir gradualmente uma camada gráfica que já carregava anos de conhecimento acumulado do ecossistema Xenia/ReXGlue.
Renderer nativo continua opcional
Apesar das correções, o projeto ainda não transformou o novo renderer em configuração padrão.
O usuário pode ativá-lo no launcher, enquanto o caminho gráfico anterior permanece disponível e continua sendo a opção padrão.
A equipe ainda solicita testes em diferentes placas de vídeo, processadores e drivers.
Os desenvolvedores pedem comparações em resolução interna 1× e 2×, além de FPS, hardware utilizado, screenshots de possíveis problemas visuais e o arquivo de log do jogo.
Portanto, a 2.0.3 deve ser interpretada como uma versão de estabilização importante, não como uma declaração de que o renderer nativo terminou seu período experimental.
Outra captura oficial do renderer DirectX 12 nativo em resolução interna 2×. O novo caminho gráfico permanece opcional enquanto os desenvolvedores coletam testes em diferentes GPUs. Imagem: Little Bit/DPRecomp.
Renderer nativo já suporta resolução interna de até 4×
O caminho DirectX 12 vem sendo desenvolvido ao longo de várias versões anteriores.
Antes mesmo da série 2.0, o projeto adicionou resolução interna de até 4×, mipmaps, formatos de profundidade do Xbox 360 e diferentes correções no recompilador de shaders.
Na versão 2.0, os desenvolvedores consideraram que elementos importantes como iluminação, céu, depth of field, reflexos e pós-processamento já estavam próximos o suficiente do comportamento esperado para ampliar os testes públicos.
Ainda existem diferenças conhecidas.
O projeto cita, por exemplo, um espelho que pode apresentar imagem duplicada, uma luz que muda conforme a câmera em uma cutscene e possíveis problemas envolvendo sombras e contornos em árvores que ainda precisam ser reavaliados.
Além disso, a versão PAL recebeu mais horas de testes do que a edição norte-americana.
RTX 5070 manteve 60 FPS em um teste anterior do desenvolvedor
As notas da versão 2.0 também incluem uma medição de desempenho realizada pelo próprio projeto.
Em uma GeForce RTX 5070, dentro da delegacia e com resolução interna 2×, o desenvolvedor registrou 60 FPS.
O renderer nativo utilizou entre 5,1 e 6,1 ms de tempo de CPU e entre 1,4 e 1,6 ms de GPU por frame naquela cena.
Esses números não são um benchmark da versão 2.0.3 e não demonstram o desempenho em todo o jogo.
Eles servem apenas como uma referência publicada pela equipe durante o desenvolvimento do novo backend.
O foco da versão 2.0.3 está na estabilidade do gerenciamento de recursos, não em um novo ganho de FPS.
Por que uma GPU pode continuar trabalhando depois que a CPU terminou?
O bug corrigido ajuda a ilustrar uma característica fundamental das APIs gráficas modernas.
A CPU normalmente prepara comandos e os envia para uma fila de trabalho. A GPU executa esses comandos em seu próprio ritmo.
Isso permite que CPU e GPU trabalhem paralelamente e melhora muito o desempenho.
Porém, essa independência cria uma obrigação para o renderer: um recurso não pode ser destruído apenas porque a CPU terminou de utilizá-lo.
Ele precisa continuar existindo enquanto houver qualquer frame pendente na GPU que ainda possa fazer referência a ele.
Se o programa destrói aquela memória cedo demais, surge uma condição semelhante a um use-after-free: o hardware tenta acessar algo que já deixou de ser válido.
Foi justamente esse tipo de situação que o DPRecomp encontrou depois da chegada do novo backend.
A correção é importante para sessões longas
Problemas desse tipo podem ser difíceis de detectar em testes rápidos.
Uma área pequena pode funcionar perfeitamente durante vários minutos porque nenhum recurso crítico é liberado no momento errado.
Já uma sessão mais longa força o jogo a carregar e descartar continuamente modelos, áreas, personagens e outros dados.
Quanto maior a quantidade de transições, maior a chance de expor erros de lifetime.
Isso explica por que a equipe continua pedindo especificamente testes prolongados.
A correção dos slots de render targets também segue essa lógica. Um recurso interno que vaza lentamente pode passar despercebido em cinco minutos e se tornar crítico depois de horas.
DPRecomp continua sendo recompilação estática, não emulação convencional
O renderer experimental também não muda a natureza principal do projeto.
O DPRecomp continua sendo um port nativo criado por recompilação estática do código PowerPC da versão Xbox 360.
As instruções do jogo são convertidas para x86-64 durante a construção do programa, em vez de serem executadas por uma CPU virtualizada durante o gameplay.
O usuário precisa fornecer sua própria cópia de Deadly Premonition para Xbox 360, em formato de imagem de disco ou arquivos extraídos.
O repositório e os releases não distribuem o default.xex nem os dados comerciais do jogo.
Além disso, o projeto possui builds separadas para os discos PAL e NTSC dos Estados Unidos.
O que realmente muda com o DPRecomp 2.0.3?
A novidade não é a existência do renderer DirectX 12. Esse recurso já havia sido apresentado anteriormente e ganhou seu principal salto público com a versão 2.0.
O delta desta atualização está na estabilidade.
Testes reais revelaram que o gerenciamento de recursos não respeitava corretamente a diferença temporal entre o momento em que a CPU deixava de precisar de um modelo e o momento em que a GPU terminava de utilizá-lo.
A 2.0.3 corrige essa causa conhecida, torna a desmontagem de objetos provenientes das threads de loading mais segura e evita o esgotamento dos slots de render targets em sessões prolongadas.
Além disso, caso outra causa de “GPU lost” exista, a instrumentação atual deve fornecer informações mais precisas para encontrá-la.
Assim, a atualização representa um passo importante para transformar o novo renderer de uma demonstração funcional em um backend que possa ser utilizado durante sessões maiores de Deadly Premonition.
O caminho DirectX 12 ainda permanece experimental e opcional. Entretanto, um dos problemas mais graves encontrados depois da chegada da série 2.0 agora possui uma causa identificada e uma correção específica no gerenciamento de recursos.
Fontes: DPRecomp 2.0.3 — release oficial | DPRecomp — notas técnicas da versão 2.0.3 | DPRecomp — notas da versão 2.0.2 | DPRecomp — introdução do renderer DirectX 12 na versão 2.0 | DPRecomp — repositório oficial.
