DLSS Frame Generation Runtime Status

A diagnostic node with no inputs and one text output shouldn't be exciting. Then you run DLSS Frame Generation, it fails twenty frames in, and you spend an afternoon wondering whether your driver, your DLL, or the gods of hardware-accelerated GPU scheduling are to blame. This node exists to stop that afternoon from happening. Queue it once, and it tells you, before any video is processed, whether the frame-generation path in this pack can actually run.

It ships with the unofficial ComfyUI-DLSS5 pack (the DLSS5 name is community shorthand, not an NVIDIA DLSS 5 SDK integration). Its sibling, the DLSSFrameGeneration node, interpolates video through a real DLSS-G worker - but only if three fragile things line up: the external dlssg-worker.exe, a compatible nvngx_dlssg.dll, and Windows HAGS. This node checks all three.

What it actually checks

Queue it and read the single STRING output. It resolves the worker and runtime paths, launches the worker with a --probe flag to confirm it boots and talks to the runtime, and reads your HAGS registry state (HwSchMode under SYSTEM\CurrentControlSet\Control\GraphicsDrivers). The verdict comes back as:

• READY - worker and runtime DLL found in the same runtime/dlssg directory, probe returned valid JSON.
• READY (HAGS WARNING) - everything works, but hardware-accelerated GPU scheduling is disabled or unreadable. Frame gen can still run, but behavior "can vary by driver and worker build," per the pack's own docs, and 3x/4x multi-frame is more likely to fall back. Turn HAGS on in Windows graphics settings to remove the variable.
• NOT READY - followed by the actual exception, which is the good part. It will name the missing piece: a worker DLL path, a runtime file that isn't there, a probe that exited nonzero, or a worker that returned garbage instead of JSON.

There are no inputs to set and nothing to configure - this is the "did my setup actually take" gate the README tells you to run after the one-click runtime installer finishes.

Wiring and use

It doesn't sit in your render graph at all. Drop it in, queue it, read the text, delete it. The only things to know: the report prints full local paths, so redact personal directory names before screenshotting it - same advice the pack gives for its main runtime status node - and a READY result is a capability check, not a per-clip guarantee. It confirms the worker probes cleanly; whether 3x or 4x actually holds up across a long clip still depends on your GPU, driver, and runtime version at encode time. 2x is the safest thing to actually render.

Installing it

Same one-time setup as the whole pack - there's no way around it, so don't try to run the status node to skip it:

# via ComfyUI Manager -> Git URL install, then restart
https://github.com/HECer/ComfyUI-DLSS5

Restart so the declared dependencies (numpy, opencv-python, Pillow, py7zr, transformers, torchvision) install. Run the pack's runtime setup node so it downloads the pinned, SHA-256-verified dlssg-worker.exe, then place your own legally obtained nvngx_dlssg.dll beside it in runtime/dlssg. Only then does this status node have anything useful to say - and if you get a NOT READY that names a missing runtime file, that's the setup step you skipped, not a bug in the node. It's a two-minute check that saves the most frustrating failure mode this pack has, and honestly the right way to learn whether your rig is even eligible before you build the whole 24→48 fps workflow around it.