Possible to redirect DLSS2 to an API-compatible implementation?

[Atemu]

Is it possible to implement DLSS2 via a DLSS-compatible FSR2 implementation such as https://github.com/PotatoOfDoom/CyberFSR2 like Latencyflex is a Reflex-compatible implementation?

That would be a great boon for non-Nvidia users.

[jp7677]

That is unfortunately outside of the scope of this project. This project provides an alternative implementation for nvapi64.dll, not for nvngx.dll and friends. DXVK-NVAPI here provides functions that allows game to see that requirements are met (e.g. what is the GPU architecture or what is the adapter LUID) and forwards D3D11 or D3D12 calls further into DXVK/VkD3D-Proton, but is does not implements anything from the real DLSS magic.

I hope this clarifies things.

[Atemu]

Thanks for the reply!

What I meant was not to implement DLSS2 inside dxvk-nvapi but to spoof the requirements and "forward" the calls to a compatible implementation such as the mod linked above.

Isn't that how the Latencyflex integration works?

[jp7677]

No, that still isn't going to work. I'm not an actual graphics programmer, so I don't know how DLSS or FSR2 looks from the application side. That said, from my understanding, the dependencies are (at least partially) the other way around, thus it is a component from the DLSS SDK that calls NVAPI. Adding Linux/DXVK support to the project you linked to is a question you should ask there.

[jp7677]

I guess this has been (somewhat) answered. That said, feel free of course to continue the discussion.

[gardotd426]

Jens I'll give it my best shot at explaining why this 1) isn't dxvk-nvapi's issue and 2) why it's not the same thing or even possible, so @Atemu won't object to you closing this issue.

@Atemu, it seems like you're conflating quite a few completely unrelated things that only have one thing in common, "they help some gaming hardware vendor's special tech run where it wouldn't ordinarily run."

By that logic, CyberFSR2 means that we can make literally every single Windows game and application run on Linux via Wine/Proton. If it's possible for CyberFSR to do put FSR in Cyberpunk 2077 (which is super easy compared to a lot of the stuff mentioned here), then surely all Win32 games and apps can work on Linux without much trouble.

What I meant was not to implement DLSS2 [I think you meant FSR2 here] inside dxvk-nvapi but to spoof the requirements and "forward" the calls to a compatible implementation such as the mod linked above. Isn't that how the Latencyflex integration works?

No, it's not how LatencyFlex works, and also you're not really making a lot of sense on how you'd expect FSR2 to work within dxvk-nvapi - which a) just tries to provide a Linux implementation of Windows's NvAPI and b) does NOT provide DLSS compatibility, DLSS compatibility for all Windows games running in Wine/Proton on Linux would be literally zero without Nvidia's nvngx.dll library. They contribute this library themselves as part of their Linux driver, and it was the "DLSS is coming to Wine and Proton next major NV driver release" news we had heard rumors about. Without Jens' work, it wouldn't matter, but nvngx.dll is obviously a very closely guarded proprietary binary .dll file that NV is not going to provide to the public as long as DLSS is at least the dominant upscaling tech in gaming, or the most advanced, or both (which is the case right now).

The creator of LatencyFlex wrote a blog post where he goes into detail on how exactly his vendor-neutral re-implementation of NV Reflex is actually 100% not Wine/DXVK/VKD3D-Proton. It is not a translation layer that "receives 'compatible calls'" from some other thing. LatencyFlex actually is just a tremendous stroke of genius where Reflex came out, the dev soon after discovered Google's BBR algorithm which is designed to fight BufferBloat. He then proceeded to start from the ground up to create a latency-reducing tool for Linux gamers that achieves mostly the same as what Nvidia Reflex does on Windows, only, while being open to users of all GPU vendors. He already knew why the rendering/input pipeline causes unneeded latency, found an ingenious way to reduce the latency, and made his own judgment calls throughout development on exactly how to design the tool. It uses NVAPI as one method that it can be injected into a game to fool the game into thinking that an Nvidia Reflex-capable GPU and display are being used, but that's only for games that already include Nvidia Reflex support. So his Reflex Alternative is using NVAPI to force enabling of the original Reflex option.

What you're talking about is a mirror-world version of that. Like I said, LatencyFlex isn't a translation/compatibility layer that takes Reflex calls and uses DXVK-NVAPI to somehow translate them into "compatible" calls for non-Nvidia or non-Windows users to still benefit from the tech. There is no such thing. He just basically made his own version, the only "API calls" involved are the game asking NvAPI if the system supports Reflex, and Latency+DXVK-NVAPI+et al responding "yep sure are." That's it.

But FSR is an open-source, vendor-neutral method of upscaling game content. Any game developer that wants to add it can add it right away, and we can all use it with no issues, regardless of our GPUs. In addition, you can already use it for games that don't have FSR or even DLSS support by using either Gamescope or Proton-GE/Proton-TKG/Wine-GE-Custom/Wine-TKG when the FSR patches are enabled.) So why on earth would you even be asking for someone to do this all over again, a third time (not counting AMD themselves), while limiting yourself to games that have DLSS support, instead of every game that's playable (like what you get with gamescope/Proton/Wine-GE/TKG)? Do you think it will make FSR better? It won't. It can't.

FSR2 vs DLSS 2.0 is NOT at all similar to DirectX12 vs Vulkan. FSR2 and DLSS 2.0 are fundamentally different, from their use or lack of use of machine learning, to their use (or lack of) dedicated hardware, and everything in between.

CyberFSR2? You seem to be rather familiar with that, correct? If that's true, then you already know that CyberFSR2 does not use the nvapi64.dll from here, but rather it uses Nvidias nvngx.dll wine library.

what you ask for is already implemented

[Atemu]

By that logic, CyberFSR2 means that we can make literally every single Windows game and application run on Linux via Wine/Proton. If it's possible for CyberFSR to do put FSR in Cyberpunk 2077 (which is super easy compared to a lot of the stuff mentioned here), then surely all Win32 games and apps can work on Linux without much trouble.

I have no idea how you arrived at that. I'm well aware that no implementation is perfect and never claimed otherwise.

What I meant was not to implement DLSS2 [I think you meant FSR2 here]

No, I specifically meant DLSS2. The API to be exact.

A game is built against the DLSS2 API at compile-time (in C/C++ terms, the headers). At runtime, the game loads the DLSS2 DLL which is a concrete object code implementation of said API. The game knows the symbol names of the routines it wants to run and dynamically links the instructions it finds in the DLL into its address space.

What I believe the FSR mod I linked does is implement the DLSS2 API using FSR2. The game links the mod's symbols rather than those from the real nvngx.dll.

What I want to know is whether it's possible to keep the real nvngx.dll in-place but forward its internal calls made to the proprietary Nvidia driver in order to implement their driver magic using a 3rd party implementation rather than Nvidia's; similar to how LatencyFlex is an implementation of the Nvidia Reflex driver magic.

that's only for games that already include Nvidia Reflex support

s/Reflex/DLSS2/. I'm not asking for injecting a DLSS2 implementation into games that don't already support DLSS2.

his Reflex Alternative is using NVAPI to force enabling of the original Reflex option.

Is that really all there is to it? LFX and Reflex alike must somehow be fed with events from the game. From the author's blogpost I gather that Reflex even has a few more events games signal to it which LFX chooses to ignore in favour of a more generic algorithm.

What you're talking about is a mirror-world version of that. Like I said, LatencyFlex isn't a translation/compatibility layer that takes Reflex calls and uses DXVK-NVAPI to somehow translate them into "compatible" calls for non-Nvidia or non-Windows users to still benefit from the tech. There is no such thing.

So did AMD when they made FSR2. It's their own thing that implements DLSS2-like features with their own original algorithms.

FSR is an open-source, vendor-neutral method of upscaling game content. Any game developer that wants to add it can add it right away, and we can all use it with no issues, regardless of our GPUs.

Yes, and it's great. In a perfect world, every game would implement FSR2 in addition to DLSS2. We don't live in that perfect world.

you can already use it for games that don't have FSR or even DLSS support by using either Gamescope or Proton-GE/Proton-TKG/Wine-GE-Custom/Wine-TKG when the FSR patches are enabled

I am not sure how you got the idea that I was talking about FSR1 at any point.

FSR2 vs DLSS 2.0 is NOT at all similar to DirectX12 vs Vulkan. FSR2 and DLSS 2.0 are fundamentally different, from their use or lack of use of machine learning, to their use (or lack of) dedicated hardware, and everything in between.

I don't care whether DLSS2 thinks it's using ML or whatever on dedicated hardware to make a decision or whether the ML algorithm is simulated using a much simpler non-ML algorithm.

It's not talking to the HW directly; it's talking to the driver. I assume that happens via nvapi. I want to make it talk to my "driver" instead for the purposes of implementing what DLSS2 uses internally.

CyberFSR2? You seem to be rather familiar with that, correct?

Not familiar in the slightest.

what you ask for is already implemented

I have no idea how you arrived at that conclusion.

[jp7677]

Is that really all there is to it? LFX and Reflex alike must somehow be fed with events from the game. From the author's blogpost I gather that Reflex even has a few more events games signal to it which LFX chooses to ignore in favour of a more generic algorithm.

There is indeed more, Games/Reflex SDK (I don't know if there is an SDK) do use NVAPI to signal hints, see https://github.com/jp7677/dxvk-nvapi/blob/master/src/nvapi_d3d.cpp#L107 and the following two methods.