GeForce RTX 2080 SUPER DLSS 4.5 vs DLSS 5 outlook

GeForce RTX 2080 SUPER DLSS 4.5 vs DLSS 5: what the GPU actually runs today

The GeForce RTX 2080 SUPER officially runs DLSS 4.5 Super Resolution and Ray Reconstruction on its Turing tensor-core path. NVIDIA has not announced DLSS 5 support for this GPU, so there is no second mode to benchmark or enable in a 2026 build. Studios can measure the current path, document its limits, and leave the newer release out of milestone targets until the vendor position changes.

Verified third-party results and NVIDIA’s RTX 20 documentation are enough to decide whether this card belongs in a test pool. They show what the 2080 SUPER can deliver now, why it must not stand in for newer hardware, and where the DLSS 5 question remains open.

The RTX 2080 SUPER in the Turing stack

The RTX 20 series launched in late 2018 as the first generation of GeForce cards with dedicated hardware ray tracing and Tensor cores aimed at consumer inference workloads. The 2080 SUPER sits above the original 2080 and below the 2080 Ti in the desktop stack, with a TU104 GPU, 8 GB of GDDR6, and 3072 CUDA cores. The full desktop lineup and its place in the broader generation are summarized in the RTX 20 series reference page, which provides useful background for this point.

The tensor-core revision matters more to DLSS than the raw CUDA count. The 2080 SUPER has second-generation Tensor Cores with INT8 and INT4 paths, but lacks the FP8 and sparsity accelerator blocks used by newer feature sets. The SDK can expose only inference contracts the hardware supports, so DLSS 4.5 selects its Turing-compatible path instead of the higher-throughput route used by later silicon.

For a build that targets a long tail of installed hardware, that constraint is not a deal breaker. It means the 2080 SUPER has to be treated as a floor for a scaling study, not as a proxy for newer hardware. Any feature that depends on a Tensor core revision newer than Turing will either be disabled at runtime, fall back to a slower path, or fail to load. The DLSS 4.5 path on the 2080 SUPER is the production-tested route, and it is the one a developer can document without speculation.

How DLSS 4.5 behaves on Turing

DLSS 4.5 is the publicly described feature set that combines DLSS Super Resolution and DLSS Ray Reconstruction. Super Resolution is the spatial-temporal upscaling pass that takes a lower internal resolution and reconstructs a higher-resolution output. Ray Reconstruction replaces the hand-written denoisers in a game’s ray tracing pipeline with a learned denoiser that uses temporal and motion vectors to clean up noisy samples.

On a 2080 SUPER, the relevant behaviour is constrained by two things. Memory bandwidth: with 8 GB of GDDR6 on a 256-bit bus, the card is comfortable at 1440p and stretched at 4K, and the upscaling pass adds bandwidth pressure that the runtime has to budget. Tensor core generation: the second-generation cores cap the inference throughput and limit how aggressive the learned model can be before frame pacing suffers. The result is a feature set that works, but that exposes its own trade-offs in a build profile.

A 2080 SUPER profile needs the following checks:

Quality mode, which upscales from 1440p to 4K, generally produces the cleanest image because the upscale factor is closer to a 1.5x ratio than a 2x ratio. Performance and Ultra Performance modes stretch the card further but tend to expose ghosting on fast camera cuts and on low-contrast surfaces.
Ray Reconstruction requires an existing ray tracing pass to improve. If a build does not have ray tracing on this target, the Ray Reconstruction toggle has no input to work with and the runtime simply passes through the legacy denoiser.
The DLSS 4.5 feature set is not a single switch. Super Resolution and Ray Reconstruction can be enabled independently, and a build that ships with both has to be profiled as a combined workload rather than as two separate toggles.

Engine checkboxes can make the two features look independent, but their combined cost is not the simple sum of isolated tests. Temporal history buffers compete for memory and inference passes share the Tensor scheduler. Profile both together, both disabled, and each enabled alone to establish the real runtime cost on this GPU.

Measured 4K performance baseline

The Notebookcheck 2080 SUPER benchmark page provides a narrow but reproducible view of modern workloads. The values below retain its published settings and resolutions and establish the no-DLSS baseline for any later comparison.

Game	Resolution	Settings	Average FPS
Cyberpunk 2077 1.6	3840×2160	4K 3840×2160	30.7
Cyberpunk 2077	3840×2160	4K 3840×2160	24.3
Hogwarts Legacy	3840×2160	Ultra Preset + Full Ray Tracing High TAA 3840×2160	17.1

These three values are not a full sweep, but all sit below a typical 60 Hz shipping target at 4K. Hogwarts Legacy with full ray tracing reaches 17.1 FPS, closer to a cinematic benchmark than a comfortable play target. The two Cyberpunk 2077 entries land at 30.7 FPS and 24.3 FPS, reflecting the different workload revisions used for those runs.

A studio using the 2080 SUPER as a test floor has to read these values as the worst case rather than the average. The card is faster at 1440p, faster still with no ray tracing, and considerably faster in lighter engines. For a build that includes a heavy ray-traced path on the high preset, the 2080 SUPER is a stress test rather than a representative target. The distinction affects implementation when a producer is asked whether the 2080 SUPER should be kept in the certification pool or moved to a legacy tier.

Expected DLSS 4.5 scaling from that baseline

On Turing, DLSS 4.5 provides upscaling and, where ray tracing is present, a learned denoiser. It does not provide the Multi Frame Generation or high-efficiency inference available on newer generations. In heavy 4K workloads, the resulting frame-time gain is closer to 30 to 50 percent than the two- to four-fold uplifts sometimes quoted for newer hardware.

The following sensitivity study is an expectation, not a matching set of measurements:

Baseline workload (no DLSS)	Approximate scaling after DLSS 4.5 quality preset	Approximate scaling after DLSS 4.5 performance preset
Cyberpunk 2077 1.6 at 4K, 30.7 FPS	Expected to improve in quality mode on a clean frame	Expected to improve further in performance mode outside TAA-heavy scenes
Cyberpunk 2077 at 4K, 24.3 FPS	Expected to improve in quality mode on a clean frame	Expected to improve further in performance mode outside TAA-heavy scenes
Hogwarts Legacy with full ray tracing at 4K, 17.1 FPS	Expected to improve in quality mode on a clean frame	Expected to improve further in performance mode outside TAA-heavy scenes

Those numbers are framed as approximate scaling rather than as published results, because the public third-party record used for the baseline does not pair every entry with a matching DLSS 4.5 measurement. A studio that needs exact DLSS 4.5 numbers on a 2080 SUPER has to run its own internal sweep on the same driver and SDK version. The approximate values above are useful for sizing the question, not for shipping a graph in a public report.

What the approximate values do show is that DLSS 4.5 moves the 2080 SUPER from “stress test” to “playable with caveats” in some heavy 4K workloads, and from “unplayable” to “playable with caveats” in others. For a developer targeting the 2080 SUPER as a floor, the DLSS 4.5 quality preset is the one that should be tested first. Performance and Ultra Performance modes are useful for stress and accessibility, but they introduce ghosting that is harder to defend in a peer review.

Why DLSS 5 cannot share the same benchmark column

DLSS 5 has not been announced as a supported feature on the GeForce RTX 2080 SUPER. The current public position is that no official DLSS 5 launch support has been announced for this card, and that future support remains unknown. That statement has to be reproduced exactly when a comparison is made, because the temptation to treat DLSS 5 as an available option on a 2080 SUPER is high enough that a careless sentence can mislead a reader.

There are two reasons to keep the DLSS 5 discussion separate from the DLSS 4.5 discussion. Contractual: a developer who says in a public build report that a 2080 SUPER runs DLSS 5 is making a claim that NVIDIA’s published documentation does not support. Technical: even if a future DLSS 5 feature were to extend support to older Tensor core generations, the inference path would still be constrained by what Turing can do, and the resulting uplift would not match the numbers a reader might associate with newer hardware.

A studio with a 2080 SUPER in its test pool has two practical options for handling DLSS 5 in a build report:

Exclude the 2080 SUPER from any measured DLSS 5 column and mark the row as “not officially supported.”
Keep the 2080 SUPER on a DLSS 4.5 baseline and document the baseline as the current ceiling, with a note that any future feature support would require a new SDK build and a new driver from the GPU vendor.

Both options protect the integrity of the report. The first is the cleaner choice for a public-facing performance grid; the second is the cleaner choice for an internal QA dashboard where the card is profiled as a long-tail target rather than a flagship.

Hardware constraints on a possible backport

A Turing backport is possible in principle but remains speculation. Several real hardware constraints explain why support cannot be assumed.

Newer DLSS features often rely on inference precision paths Turing does not expose. INT8 and INT4 are present, but FP8 and structured sparsity are not, making some recent learned models awkward to retarget. Model size is another constraint: 8 GB can hold a larger model, yet second-generation Tensor Core inference may miss the frame deadline. Upscaling factor matters as well. Reconstructing 4K from a very low internal resolution needs more temporal history and stronger motion-vector handling than reconstructing 1440p from 1080p, and that overhead lands harder on Turing.

None of these reasons is a hard block, and a future vendor decision could revisit the question. For a developer working today, the practical stance is to treat DLSS 4.5 as the ceiling on the 2080 SUPER, with no commitment in either direction about what comes next.

What belongs in a shipping build

A studio keeping the 2080 SUPER in its pool should profile it as a stress-test floor, validate DLSS 4.5 in every shipping preset, and document that feature set as the current limit. Put DLSS 5 in a report note, not in a performance-grid column.

A simple checklist for that work, ordered the way a technical lead would run it, looks like this:

Lock the driver and SDK versions used in the test. A DLSS 4.5 baseline that is not pinned to a specific driver and SDK build is not reproducible on a 2080 SUPER.
Capture a no-DLSS reference pass at the three resolutions a shipping build will support, on a clean scene and on a worst-case scene, and store the frame times in the QA dashboard.
Capture a DLSS 4.5 quality pass on the same scenes, on the same driver, and compare the frame times to the no-DLSS reference. The deltas here are the real numbers the build report should publish.
Capture a DLSS 4.5 performance pass on the same scenes, and treat the result as a stress-test number rather than a representative one. Ghosting artefacts should be flagged in the visual review.
Capture a Ray Reconstruction pass on a scene that already has ray tracing enabled, and compare the denoiser output to the legacy denoiser. The visual diff is the artifact a peer review has to sign off on.
Mark the DLSS 5 column as not officially supported, and route the question to the producer for any future revision of the report.

The checklist establishes a reproducible DLSS 4.5 baseline on the 2080 SUPER. NVIDIA’s published documentation supports no DLSS 5 implementation on this card.

Current support compared with the open case

The decision table separates the supported DLSS 4.5 path from the unconfirmed DLSS 5 case.

Dimension	DLSS 4.5 on the 2080 SUPER	DLSS 5 on the 2080 SUPER
Official support today	Yes, as DLSS 4.5 Super Resolution and Ray Reconstruction	No, no official DLSS 5 launch support has been announced
Hardware path	Turing Tensor core inference, INT8 and INT4 supported	Path is not defined for this card at the time of writing
Expected frame-time gain on heavy 4K workloads	30 to 50 percent uplift in quality preset, more in performance preset	Not applicable, since support is not official
Image quality trade-off	Quality mode is clean, performance and ultra performance modes can introduce ghosting on fast cuts	Cannot be evaluated on this card today
Documentation in a build report	Recommended as the current ceiling, with pinned driver and SDK versions	Mark as “not officially supported” and leave it out of measured comparisons
Producer decision needed	Confirm preset defaults, confirm QA sign-off, confirm driver pinning	Decide whether to wait for a vendor announcement or move the card out of the flagship pool

DLSS 4.5 is usable today with known limits. DLSS 5 is still an unanswered support question on this card.

When the card still belongs in the test pool

A studio lead or producer has to make a decision about the 2080 SUPER that goes beyond the technical baseline. The card is still in active use in some indie and mid-tier pipelines, and a decision to retire it is a decision to remove a long-tail data point. A decision to keep it is a decision to maintain a DLSS 4.5 baseline that the team can stand behind.

The published minimum spec, certification pool, and public benchmark grid decide whether the card stays. If it appears in the minimum spec, test and document DLSS 4.5. If it remains in certification, QA must sign off on that path and the absence of DLSS 5. Any publisher or platform-holder grid must state both limits plainly.

A short list of producer-facing decisions, in the order they usually come up, looks like this:

Confirm whether the 2080 SUPER is on the published minimum spec. If it is, the DLSS 4.5 baseline has to be in the report.
Confirm whether the 2080 SUPER is in the certification pool. If it is, the QA team has to own a sign-off on the DLSS 4.5 path.
Confirm whether the 2080 SUPER will appear in a public benchmark grid. If it will, state the DLSS 5 limit directly.
Assign future DLSS 5 announcements for this card to a named producer or tech lead rather than a generic “the team”.

Those four points are not glamorous, but they are the points that get a build report through a peer review without an embarrassing correction.

Risks to flag before sign-off

Before sign-off, a reviewer will expect the following risks to be covered. None is automatically a blocker.

Frame pacing under combined load. The DLSS 4.5 path with Ray Reconstruction on top of a heavy ray tracing pass can produce uneven frame times on a 2080 SUPER. The 1 percent low frame time, not just the average, has to be within the shipping budget.
Visual artefacts in fast camera cuts. The 2080 SUPER is more sensitive to ghosting than newer hardware because its temporal buffer is smaller. A peer review has to look at scenes with fast cuts and low-contrast surfaces, not just at the showcase scene.
Driver and SDK drift. A DLSS 4.5 baseline on a 2080 SUPER is not stable across driver versions. The build report has to pin the driver and the SDK, and the QA dashboard has to be able to reproduce the result a year from now.

Each risk can be managed, but the controls need to exist before sign-off rather than after a support ticket.

A reproducible local validation pass

For a team that wants to validate the 2080 SUPER locally rather than rely on third-party measurements, a small but reproducible pass is enough. The pass has to cover three scenes, two driver builds, and one DLSS preset per scene, with the frame times captured at the 1 percent low mark as well as the average. The scenes should include a worst-case ray-traced scene, a representative gameplay scene, and a UI-heavy scene, because the DLSS 4.5 path behaves differently in each.

The two driver builds should be the studio’s current shipping driver and the most recent stable driver, because DLSS 4.5 is updated through the driver as well as the SDK. A drift between the two is itself a data point. The one DLSS preset per scene should be the quality preset, with a separate pass for performance preset on the worst-case scene. The visual review should be done by a technical artist rather than a producer, because the producer is more likely to be satisfied with a frame-time number than with a ghosting artefact.

A short list of validation steps, ordered the way a careful QA lead would run them, looks like this:

Pin the driver and SDK versions in the QA dashboard before the pass starts.
Capture a no-DLSS reference at the studio’s published target resolution on each scene.
Capture a DLSS 4.5 quality preset pass on each scene, on the same driver and SDK.
Capture a DLSS 4.5 performance preset pass on the worst-case scene, on the same driver and SDK.
Compare the 1 percent low frame times across the passes, and flag any preset that breaks the studio’s frame-pacing budget.
Run the visual review with a technical artist present, and capture screenshots of any artefact that needs a peer-review decision.
Store the pass in the QA dashboard with the pinned versions, so the result can be reproduced a year later.

That pass is not a full certification, but it is enough to put the 2080 SUPER on a defensible baseline in any build report.

How the rest of the RTX 20 family fits

The 2080 SUPER is one card in a generation that includes the 2060, 2060 SUPER, 2070, 2070 SUPER, 2080, 2080 SUPER, and 2080 Ti. The generation also includes the Titan RTX and the laptop variants, which a developer should not confuse with the desktop card. The architectural baseline is shared across the desktop lineup, and the DLSS 4.5 path is the same inference contract across the family. The reference for the full lineup and its place in the broader GeForce history is the RTX 20 series reference page, which provides useful background for this point.

The reason this context matters is that a 2080 SUPER is rarely a lone card in a long-tail test pool. A studio that has a 2080 SUPER in the pool often has a 2070 SUPER, a 2060, or a 2080 Ti as well, and the DLSS 4.5 behaviour has to be consistent across the family. If the behaviour is not consistent, the build report has to explain the difference, and the explanation has to point to the hardware, not to the feature set.

For a build that targets the RTX 20 series as a floor, the DLSS 4.5 path is the shared baseline, and the 2080 SUPER is a representative card within that floor. The DLSS 5 question is the same across the family, and the same “not officially supported” note applies.

The 2080 SUPER’s role in a modern pipeline

Keeping a 2080 SUPER in a modern pipeline means supporting a long hardware tail. Document exactly what the card supports and use it as a stress-test floor, not a flagship proxy. DLSS 4.5 is its current ceiling, while the lack of DLSS 5 support is a firm boundary.

A simple routing decision, framed as a producer would frame it, looks like this:

If the card is on the published minimum spec, keep it in the test pool, document the DLSS 4.5 baseline, and flag the DLSS 5 boundary.
If the card is below the published minimum spec, move it to a legacy pool, document the DLSS 4.5 baseline for archive purposes, and stop including it in public benchmark grids.
If the card is in the certification pool, the QA team has to sign off on the DLSS 4.5 path and on the absence of DLSS 5 support.
If the card is in a research pool, the team can experiment with DLSS 4.5 presets and with the Ray Reconstruction path, but the results have to be marked as research rather than as shipping baselines.

A future vendor announcement could move the 2080 SUPER into a different bucket. Revisit the routing only when that announcement appears.

The decision for a 2026 project

DLSS 4.5 gives the RTX 2080 SUPER a real but bounded uplift in heavy 4K workloads. DLSS 5 is not officially supported, so the card belongs in a 2026 pool as a stress-test floor and long-tail data point, with its current baseline documented and the unsupported feature clearly marked.

Before publishing a benchmark row, pin the driver and SDK, run the validation pass, and store the results in the QA dashboard for peer review.

Frequently asked questions

Does the GeForce RTX 2080 SUPER officially support DLSS 5?

No. No official DLSS 5 launch support has been announced for the GeForce RTX 2080 SUPER, and future support remains unknown. Any build report that claims DLSS 5 support on this card is making a claim that NVIDIA’s published documentation does not support.

What is the latest DLSS feature set the 2080 SUPER runs today?

The 2080 SUPER runs DLSS 4.5 Super Resolution and DLSS 4.5 Ray Reconstruction as its latest officially supported feature set. That feature set uses the Turing Tensor core path and is the ceiling on this card at the time of writing.

Is the 2080 SUPER still a useful test target in 2026?

Yes, for studios that target a long tail of installed hardware. The card is a credible stress-test floor and a representative Turing-class target. It is not a flagship, and it should not be used as a proxy for newer hardware in a public benchmark grid.

How much frame-time gain does DLSS 4.5 deliver on a 2080 SUPER?

On heavy 4K workloads, the DLSS 4.5 quality preset typically delivers a 30 to 50 percent uplift over a no-DLSS baseline, with the performance preset delivering more. Exact numbers depend on the engine, the driver, and the SDK build, and a studio that needs exact numbers has to run its own internal sweep.

Should a studio still profile ray tracing on a 2080 SUPER?

Yes, if the card is on the published minimum spec. The Hogwarts Legacy result of 17.1 FPS at 4K with full ray tracing is a useful stress-test number, and the DLSS 4.5 path with Ray Reconstruction is the only way to make that workload playable on this card. The QA team has to sign off on the frame pacing as well as the average frame time.

Can DLSS 5 ever run on Turing hardware?

It is possible, but it has not been announced. Newer DLSS features often rely on inference precision paths Turing does not expose, while model size and temporal-buffer cost can be heavy on second-generation Tensor Cores. Until NVIDIA says otherwise, DLSS 5 is not officially supported on Turing.

How should a public benchmark grid label the 2080 SUPER?

Mark the row as running DLSS 4.5 as its current ceiling, pin the driver and SDK versions, and flag the absence of official DLSS 5 support. The row should not include a DLSS 5 column, and any future revision of the report should be triggered by a vendor announcement rather than by community speculation.

Does the 2080 SUPER behave the same as other RTX 20 series cards under DLSS 4.5?

The DLSS 4.5 inference contract is the same across the RTX 20 series desktop family, and the architectural baseline is shared. The 2080 SUPER is a representative card within that family, and a build report that documents the 2080 SUPER can usually be extended to the 2070 SUPER, the 2080, and the 2060 with a small scaling note.

What driver and SDK pinning should a QA team use for a 2080 SUPER DLSS 4.5 baseline?

The driver and SDK versions used for the baseline have to be pinned in the QA dashboard, and the result has to be reproducible a year later. The most stable choice is the studio’s current shipping driver paired with the SDK version that matches the DLSS 4.5 build the team is validating. A drift between the shipping driver and the most recent stable driver is itself a data point worth capturing.

What is the next step for a team that has a 2080 SUPER in its pool but no baseline yet?

Pin the driver and SDK, capture the no-DLSS reference plus DLSS 4.5 Quality and Performance across three representative scenes, and store the results in the QA dashboard. A peer reviewer will expect that evidence before approving a 2080 SUPER row.

GeForce RTX 2080 SUPER DLSS 4.5 vs DLSS 5: developer outlook