By using this site, you agree to our Privacy Policy and our Terms of Use. Close

Forums - PC - DLSS 5 is brilliant.

 

DLSS 5

Epic 4 9.76%
 
Great 7 17.07%
 
Good 5 12.20%
 
Decent 5 12.20%
 
Poor 6 14.63%
 
Bad 12 29.27%
 
No opinion 2 4.88%
 
Total:41
HoloDust said:

@sc94597

I think you're confusing nVidia's quote of how the model was trained with what it actually takes as inputs at runtime.

Nvidia's own technical paper have clarified that while they used G-buffers like albedo, normals, and depth during training as 'consistency supervision' to teach the model, the network does not receive them as explicit runtime inputs. At inference, DLSS 5 only takes the rendered color frame, motion vectors, and temporal history. It does not have live geometric awareness or material data. It's literally looking at a flat 2D image and using its training to guess (or hallucinate) what the lighting and materials should look like.

That is exactly why it can't understand off-screen or occluded geometry, and why AMD's paper is IMO better path forward. Their approach doesn't just look at a flat frame, it's natively integrated into the rendering pipeline. It explicitly uses actual runtime scene data (normals, albedo, roughness, metallic) and live radiance cues to generate the indirect illumination. From what I understand, AMD approach actually knows the live geometry and material properties of the scene it's generating illumination for (although it's still screen-space approximation of GI), whereas DLSS 5 is just a highly trained 2D post-process approach.

That said, I understand why some folks are mesmerized with DLSS 5 - it works today (albeit at heavy cost), and it gives...well, (arguable) results.

Ah, that paper was actually helpful. So the g-buffers are used in the training objective with derived features (to better meet the objective) doing the heavy work to maintain semantic consistency in inference.  

This is what they say about the topic. 

Artistic intent preservation. The output preserves what the artists authored: geometric structure, object and character identity, material identity, composition, and the organization of light and shadow. Nothing enforces this at runtime — the supervision that encourages it acts during training, and every generated change carries some risk of drifting from the authored scene. Section 2.1 describes the supervision, and Section 4 measures the preservation.
Conditioning on rendered RGB alone, however, provides a very strict constraint on the output that introduces challenges in achieving high realism. RGB entangles scene content with the appearance already produced by the renderer. If the model follows the input too literally, it tends to reproduce the same edges, colors, textures, and baked shading, leaving too little freedom to improve the final appearance. If the model is given too much freedom, it can drift from the authored content. We resolve this challenge during training rather than at the runtime interface. During training, we use renderer-derived albedo, surface normal, and lighting information to provide attribute-specific consistency supervision. Albedo provides illumination-independent chromatic information, surface normal provides local orientation information, and the lighting-derived signals supervise the authored illumination structure. These signals are used only during training and are not inputs to the shipped model. Artistic intent that is not already expressed in the rendered frame enters through the artistic-direction control of Section 3. 
Existing image generative models commonly rely on text embeddings, exemplar images, or spatial control fields such as depth, edges, segmentation, and pose (Esser et al., 2024; Imagen 3 Team, 2024; Black Forest Labs et al., 2025; Wu et al., 2025; Li et al., 2024). These conditions are effective for general-purpose generation and editing, but they do not uniquely determine the object identities, materials, visibility relationships, lighting decisions, and pixel-aligned detail contained in an engine-rendered frame. DLSS 5 is therefore conditioned on the rendered frame itself.

The immediate advantage I would see in providing the actual inputs would be performance. You can have a smaller, more efficient model. They probably will do that in a future iteration of it. Maybe they wanted to start out simple, release something, and then iterate. But I do think DLSS5 is a stop-gap before Nvidia moves to online learners (which they and AMD have already implemented into their PT pipelines, to an extent.) 



Around the Network
sc94597 said:

The immediate advantage I would see in providing the actual inputs would be performance. You can have a smaller, more efficient model. They probably will do that in a future iteration of it. Maybe they wanted to start out simple, release something, and then iterate. But I do think DLSS5 is a stop-gap before Nvidia moves to online learners (which they and AMD have already implemented into their PT pipelines, to an extent.) 

Yeah, I'm thinking it's current stop gap as well - it works, it's easier to implement, even if result are somewhat questionable, compared to what fully integrated pipeline approach would give, so I expect them to move to more in-engine approach in the future.

Of course, maybe their idea is that everything looks better yassified, in which case it's already doing a great job.