search

ValveSoftware / Proton

Compatibility tool for Steam Play based on Wine and additional components
Other
24.34k stars 1.06k forks source link

[Feature Request] Consider adding option to translate DLSS2/DLSS3 to FSR2/FSR3 #5937

Open SaltyBet opened 2 years ago

SaltyBet commented 2 years ago

Feature Request

I confirm:

Description

Recently, someone created a mod to map DLSS calls to FSR 2.0 calls for Cyberpunk.

See:

Quote from the mod creator:

This mod attempts to replace DLSS with FidelityFx Super Resolution 2.0. The mod is still in development, but early results are already quite impressive: My GTX 1080 is able to run Cyberpunk in 4k with about ~45 FPS which is a 2x improvement compared to the native 4k performance while having a very minor quality impact. Also, yes! this is mod is compatible with any AMD, Intel, and Nvidia GPU that can handle Cyberpunk.

How does this work?

Both FSR 2.0 and Nvidia DLSS are temporal upscalers and work (except for some minor differences) very similar. This means that both systems need similar data to work. Luckily, NVIDIA publishes its DLSS implementation as a dynamic library ( a dll file). This allows us to simply replace the DLL in question with our own version that is able to translate NVIDIA DLSS to FSR 2.0 commands. API reimplementations like Wine or DXVK work in a similar way.

Based on the previously mentioned info, this feature request is for you guys to evaluate if incorporating something similar to Proton in general, for games using DLSS, is something both possible and desirable.

SaltyBet commented 2 years ago

Latest developments:

niansa commented 2 years ago

That sounds like a pretty damn interesting idea, but afaik the DLSS API is not compatible between games? Not sure. I am not really into this topic, I can only repeat what I learned from others :D

SaltyBet commented 2 years ago

That sounds like a pretty damn interesting idea, but afaik the DLSS API is not compatible between games? Not sure. I am not really into this topic, I can only repeat what I learned from others :D

Devs incorporate the DLSS functionality on their games, and ship it bundled with the release library (Windows, Linux).

SaltyBet commented 2 years ago

Latest developments:

matyat commented 2 years ago

The only issue with implementing this generically is that FSR2.0 requires parameters that DLSS does not, specifically the camera FOV, near plane, and far plane. The above mods have a kludge to extract that data, but it's only possible on a per game (and per build) basis.

Examples: Cyberpunk 2077 Red Dead Redemption 2

SaltyBet commented 2 years ago

The only issue with implementing this generically is that FSR2.0 requires parameters that DLSS does not, specifically the camera FOV, near plane, and far plane. The above mods have a kludge to extract that data, but it's only possible on a per game (and per build) basis.

Examples: Cyberpunk 2077 Red Dead Redemption 2

While perusing the CyberFSR2 repo, I found this comment:

I tried to implement ViewMatrixHook in the same way as it is done for Cyberpunk2077.exe, but unfortunately quickly ran into some difficulties. Although I could find the vertical field of view value in the game's memory, I couldn't get a static address to it or find the near/far plane values at all. Luckily, from my testing it seems that these values are not as important as I expected (at least in Dying Light 2).

For the field of view, while using a lower value than the actual in-game FOV reduces the image quality, using a larger FOV did not appear to change the image quality. I hardcoded ViewMatrixHook::GetFov to return a vertical field of view of 77, the largest value possible to set from the in-game menu. When I decreased the in-game FOV to the minimum of 47, the image quality appeared to be good even though the FSR 2.0 library was receiving a larger value. Even in Cyberpunk, using a larger FOV for FSR than the in-game value did not appear to change image quality.

For the near/far plane values, I set them to as large of a range as possible. Specifically, ViewMatrixHook::GetNearPlane returned zero and ViewMatrixHook::GetFarPlane returned a floating point infinity value. I am less certain that these values will work in other games, especially since the far plane "is used only used in case of non infinite depth", but it seemed to work fine in Dying Light 2.

If using fixed values like these works for most other games, it would be possible to provide suitable defaults for the ViewMatrixHook functions and only access the game's memory for the actual values if necessary.

Checking ViewMatrixHook.cpp, it seems there are similar default values defined:

default:
    return std::make_unique<ViewMatrixHook::Configured>(
        config.VerticalFOV.value_or(60.0f),
        config.FarPlane.value_or(std::numeric_limits<float>::infinity()),
        config.NearPlane.value_or(0.0f)
    );

From that information, it seems, at least initially and specifically related to the translation layer part, that all 3 parameters can have sensible values defined, and it's a possibility (to be confirmed on a per-game basis) things might just work (as is the case for Dying Light 2).

SaltyBet commented 2 years ago

Latest developments:

SaltyBet commented 2 years ago

Latest developments:

SaltyBet commented 1 year ago

Latest developments:

abc-mikey commented 1 year ago

I've gotten CyberFSR2 (aka DLSS2FSR) working with Control under proton.

They appear to be using ini files to tweak the FOV and near and far planes on a game by game basis.

This would be an amazing feature for proton.

SaltyBet commented 12 months ago

Latest developments:

SaltyBet commented 10 months ago

Latest developments:

JosVerheij commented 5 months ago

If this is being considered, adding support for XeSS would be appreciated.

On the Windows side, https://github.com/cdozdil/OptiScaler is making great progress replacing DLSS with either FSR or XeSS.

SaltyBet commented 3 months ago

Latest developments: