Paid Plugins + Scripts VaM DLSS NR and DLAA Plugin RTX 20/30/40/50

[leon12343]

No vr, no play...when will vr be implemented?

 

[leon12343]

Are you really trying to monetize on something that was kindly extracted, adapted, and released for free by other communities and ppl
just because all you did was adding a 10min UI (perhaps even made with the AI) which recall the same features of the reshade addon version with absolutely nothing more and nothing less?

Some ppl are really without any shame.

You're absolutely right! So, when is your free plugin due? It's a 10 minute work for a skilled dev such as your self..

 

[FreeMaster69]

Bug report: RTX 3090 NR causing GPU reset / TDR

Hi UncleBurrito,

I’ve been testing VaM DLSS 1.0.2 quite heavily and I’m getting repeatable full GPU/display resets when using Neural Rendering. I’ve done quite a bit of isolation testing, so I thought the details/logs might help you track down a stability issue, particularly on RTX 30-series/Ampere.

System

• VaM 1.22.0.13, Desktop mode
• Windows 11
• RTX 3090 24GB, MSI SUPRIM X
• Ryzen 7 5800X3D
• 64GB RAM
• BepInEx 5.4.23.5
• Plugin: VaM DLSS 1.0.2 build DCA6A18E

Main symptom

After NR has been running for a while the monitors go black and do not recover properly. Windows appears to reset the NVIDIA GPU, but the display generally remains unusable and I have to reboot.

This is not just VaM crashing. The plugin log detects the GPU/device being removed/reset.

I have reproduced it with NR alone, so DLSS Super Resolution is not required to trigger the problem.

Crash example 1, latest NVIDIA driver

With NVIDIA 616.56:

• DLSS SR OFF
• NR ON
• 1920x1080
• MSAA 8x
• NR-only render chain

The log eventually reported:

NR HAS STOPPED PRODUCING

device=REMOVED hr=0x887A0007 (the device was reset by the system.)

chain: source -> NR -> screen

It had reached approximately 9,623 frames before the reset.

Crash example 2, older driver + NVIDIA Debug Mode

To rule out the current driver and my MSI factory OC, I rolled back to NVIDIA 610.74 and enabled NVIDIA Debug Mode, which forces the GPU back toward NVIDIA reference clocks.

It still crashed.

In this run:

• DLSS SR OFF
• NR ON
• NR preset/style/strength values left at defaults
• 2 NR passes
• NVIDIA Debug Mode ON
• Driver 610.74

The plugin reported:

device=REMOVED hr=0x887A0006

(the GPU stopped responding and Windows reset it (TDR).)

chain: source -> NR -> screen

At that point it showed:

running - 731 frames

Immediately after the device loss there are also large numbers of D3D11 null-buffer / failed texture operations, which I assume are consequences of the device already having been removed.

The same log shows repeated NR render-target rebuilds and switching between 2560x1440 and 1920x1080 during the session. At 2560x1440 the source was ARGBHalf/HDR with MSAA 4x. The final NR instance before the TDR was 1920x1080 with 2 passes.

DLSS + NR has also crashed

I have another log where both DLSS and NR were active. That one produced:

D3D11: Failed to create RenderTexture ... error 0x887A0005

followed by:

device=REMOVED hr=0x887A0007

chain: source -> DLSS -> NR -> screen

So DLSS+NR can trigger it too, but importantly the NR-only tests prove DLSS is not necessary to reproduce the issue.

Isolation testing

• VaM + BepInEx with your plugin removed/disabled has been stable.
• Your plugin loaded with NR and DLSS both OFF has also been stable.
• The crashes start when the NR rendering path is actually active.
• I tried NVIDIA 616.56 and 610.74.
• I tried NVIDIA Debug Mode to remove the SUPRIM X factory overclock as a variable.
• Debug Mode did not prevent the TDR.
• I have had NR-only sessions run successfully for quite a while as well, so it is intermittent rather than an immediate initialization failure.
• 2-pass NR can run correctly and looks excellent, but has also produced the TDR above.

I also had a Windows dump from one of the crashes which WinDbg identified as:

DPC_WATCHDOG_VIOLATION (133)

with:

nvlddmkm.sys

and bucket:

0x133_ISR_nvlddmkm!unknown_function

I realise that only tells us the NVIDIA driver ultimately became stuck, rather than necessarily identifying what caused the GPU workload to stall.
Potential area to investigate

Since NR appears to be the common factor, I wonder if there could be an Ampere-specific issue around the NR D3D12 path, shared resources/fences, command submission, or too many NR frames/resources being in flight.

The interesting part to me is that when it fails, the plugin reports nothing retiring, followed by a real TDR/device removal rather than simply an NR evaluation error.

If it would help, I’m happy to test experimental builds aimed specifically at RTX 3090/Ampere stability, including builds with more conservative synchronization, fewer outstanding NR submissions, additional fence/device-removal diagnostics, or anything else you want tested.

I can also provide the complete BepInEx and VaM logs from the failed runs.

Thanks. The NR effect itself is extremely impressive, particularly 2-pass Natural, so I’m keen to help get this stability issue pinned down.