Add DLSS 2.0 support

[ghost]

Describe the project you are working on

I am working on a 3D Horror Game World with 2K textures

Describe the problem or limitation you are having in your project

As the GPU Market tends to shift to AI up- and downscaling, games will tend to have GLSS in the future more likely. So first of all why shouldn't Godot have it, but everyone else? 2. It gives pretty much every game a major performance boost. 3. Even AMD will soon announce their FidelityFX driver, which will have their so called Super Resolution.

@ https://techengage.com/best-gaming-graphics-cards-gpus/

Describe the feature / enhancement and how it helps to overcome the problem or limitation

DLSS helps games with bad performance on higher settings in an immense way. It would overcome some of the limitations Developers get with considering the Hardware of Players.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I personally don't know. NVIDIA for example has a DLSS beta program or you need to consultate a NVIDIA Developer to talk it out.

If this enhancement will not be used often, can it be worked around with a few lines of script?

I don't think it can be worked around as it is from the companys themselves

Is there a reason why this should be core and not an add-on in the asset library?

You could see DLSS as an Rendering enhancement and I don't think changing the rendering as an add-on is such a good idea. I don't know how big the program itself is, so if it is too big for Godot (in terms of Volume Space) then it could be added the same way as the Android Build Template.

Thanks for reading :)

[volzhs]

accroding to wikipedia

DLSS 2.0 works as follows:[14]

• The neural network is trained by Nvidia using "ideal" images of video games of ultra-high resolution on supercomputers and low resolution images of the same games. The result is stored on the video card driver. It is said that Nvidia uses DGX-1 servers to perform the training of the network.[15]
• The Neural Network stored on the driver compares the actual low resolution image with the reference and produce a full high resolution result. The inputs used by the trained Neural Network are the low resolution aliased images rendered by the game engine, and the low resolution, motion vectors from the same images, also generated by the game engine. The motion vectors tell the network which direction objects in the scene are moving from frame to frame, in order to estimate what the next frame will look like.[16]

[mrjustaguy]

DLSS 2.0 Cannot be added to the game engine (or any game engine really).. It has to be implemented on a Game by Game basis, and is not general enough to work on a Game engine basis. DLSS 3.0 or further maybe when the AI gets more general, or efficient enough that the AI training for the game can take place on local hardware instead of needing very powerful Servers to do so.

[ghost]

DLSS 2.0 Cannot be added to the game engine (or any game engine really).. It has to be implemented on a Game by Game basis, and is not general enough to work on a Game engine basis. DLSS 3.0 or further maybe when the AI gets more general, or efficient enough that the AI training for the game can take place on local hardware instead of needing very powerful Servers to do so.

I am sorry to say but DLSS 2.0 is not per game basis. It's per Engine. See: https://developer.nvidia.com/dlss

[mrjustaguy]

Ok my bad, I was under the impression that DLSS 2.0 was still not general enough and that it too needed a per-game training.

[Calinou]

DLSS is a proprietary library; we can't integrate it officially in Godot. Since this feature must be implemented as a third-party effort, I'll close this as godot-proposals is only meant to discuss features to be added to core Godot.

Even AMD will soon announce their FidelityFX driver, which will have their so called Super Resolution.

When (and only when) AMD makes this solution public, it should be discussed in a separate proposal. We'll need to see if it's actually open source-friendly, because GPUOpen solutions have historically not always been open source (see RadeonRays 2.0 vs 4.0).

[mahdisml]

DLSS is a proprietary library; we can't integrate it officially in Godot. Since this feature must be implemented as a third-party effort, I'll close this as godot-proposals is only meant to discuss features to be added to core Godot.

Even AMD will soon announce their FidelityFX driver, which will have their so called Super Resolution.

When (and only when) AMD makes this solution public, it should be discussed in a separate proposal. We'll need to see if it's actually open source-friendly, because GPUOpen solutions have historically not always been open source (see RadeonRays 2.0 vs 4.0).

https://github.com/godotengine/godot-proposals/issues/2809

[tonymacx86PRO]

Add DLSS now! Its already open source https://github.com/NVIDIA/DLSS

[Calinou]

Add DLSS now! Its already open source NVIDIA/DLSS

DLSS is still under a proprietary EULA: https://github.com/NVIDIA/DLSS/blob/main/LICENSE.txt Its full source code is also not publicly available – you have to dynamically link against a proprietary DLL to implement DLSS in an engine. (The DLSS 3 SDK is also not publicly released yet as of writing.)

Only NIS (NVIDIA's spatial upscaler, equivalent to FSR 1.0) is open source. Since FSR 1.0 is already present in 4.0.beta, I don't see much point in adding NIS. In general, FSR 1.0 is considered to look slightly better in practice while also being faster. NIS goes for a more conservative approach but ends up being more expensive, making it a less "bang for buck" spatial upscaler.

There are already plans to integrate FSR 2.0 in future 4.x releases.

Edit: FSR2 will be available in Godot 4.2: https://github.com/godotengine/godot/pull/81197

[MikeZTM]

Add DLSS now! Its already open source NVIDIA/DLSS

DLSS is still under a proprietary EULA: https://github.com/NVIDIA/DLSS/blob/main/LICENSE.txt Its full source code is also not publicly available – you have to dynamically link against a proprietary DLL to implement DLSS in an engine. (The DLSS 3 SDK is also not publicly released yet as of writing.)

Only NIS (NVIDIA's spatial upscaler, equivalent to FSR 1.0) is open source. Since FSR 1.0 is already present in 4.0.beta, I don't see much point in adding NIS. In general, FSR 1.0 is considered to look slightly better in practice while also being faster. NIS goes for a more conservative approach but ends up being more expensive, making it a less "bang for buck" spatial upscaler.

There are already plans to integrate FSR 2.0 in future 4.x releases.

https://github.com/NVIDIAGameWorks/Streamline

They have an open-source wrapper for both XeSS and DLSS and it's MIT licensed so should be compatible. I think implementing this is benefiting a lot of users as it's quite inefficient to run FSR2 on NVIDIA and Intel GPUs. Those card are much more capable of much better image quality and potentially lower latency. Starfield already generating a lot of noise on that front and it's pretty clear future game developer will facing same request from their PC audience.

Obviously, developer will still need to put proprietary blobs to actually enable those features, but this makes it possible to have almost ready-to-use support and keep blobs out of the engine.

[MikeZTM]

The wrapper is MIT-licensed, but the DLSS library is not (its source code isn't even available). Compiling your own version of Streamline also has limited functionality (namely, no DLSS Frame Generation). Quoting from Streamline's README:

As of SL 2.0.0, it is now possible to recompile all of SL from source, with the exception of the DLSS-G plugin. The DLSS-G plugin is provided as prebuilt DLLs only. We also provide prebuilt DLLs (signed) for all other plugins that have source. Most application developers will never need to rebuild SL themselves, especially for shipping; all of the pieces needed to develop, debug and ship an application that integrates SL and its features are provided in the pre-existing directories bin/, include/, and lib/. Compiling from source is purely optional and likely of interest to a subset of SL application developers. For developers wishing to build SL from source, see the following sections.

It's better than nothing and DLSS-G plugin can be added by game developer without help from engine, though maybe not optimal in that case.

• It only supports Windows. DLSS can be made to work on native Linux applications – even though there are no such applications as of writing, the compiled DLSS libraries do have Linux ports.

As far as I know, currently all Linux DLSS enabled title are running through proton and using an open source NVAPI implementation to pass through the data to Linux native DLSS binaries. I understand this limitation and the wish to have native Linux port of games, but if this wine passthrough thing could help more gamer to leave Windows I still think it is a good idea to have it than not. And things may change if Intel actrully honor their open-source claim of XeSS or NVIDIA helping streamline to get native Linux support. Or even better, AMD stop their insane action and allow adding FSR2 support to Streamline. It's license compatible after all.

• It looks difficult to build from source and integrate into another buildsystem (in our case, SCons).

That's a valid issue. But I think as Streamline isn't changing a lot maybe it could be kept as a separate blob build. Especially for its Windows only situation for now.

• It doesn't support FSR, although we have our own implementation now, so it's not really an issue.

It doesn't support FSR2 for reasons and I think everyone agrees that we don't want a Starfield situation happens on game developers. I hope AMD could let it support FSR2 so no more complains. And adding streamline support on top of FSR2 implementation is quite straightforward.

Also, remember that DLSS still requires you to inform NVIDIA of your game's release if it's a commercial project. FSR has no such restriction.

That's on game developer. You don't need to inform NVIDIA or Intel for using Streamline. Since developer need to get DLSS/XeSS SDK blobs from them anyway, they should follow what EULA that came with those files.

I'm not making this something higher priority than it should be, there's much more important work to be done, just we may have to deal with this since FSR will always lagging behind by quite some margin until AMD finally decide to put some CDNA gene into RDNA to properly run a better kernel. And by that time nobody can guarantee AMD will make that FSR version open-source.

Plus this one should be a lower hanging fruit since we have FSR2 support. Making developer to do the modder's job isn't ideal anyway.

[mrjustaguy]

Oh where do I start...

1. AMD isn't blocking FSR2 integration into streamline, that's a myth. They just aren't supporting it, but they cannot block it as they're releasing FSR2 under an MIT license.
2. Starfield situation has nothing to do with this, the game barely got shipped even after all the delays, thanks to AMD. It's a classic Bethesda game, what the hell did everyone expect? Also why would AMD (that did quite a bit of work for Bethesda's engine side to get it shippable) bother pushing their competitor's tech when they cannot use it themselves, and their alternative works on everything? It's a waste of their recourses
3. DLSS is an absolute QA Nightmare. That is why Game devs are not implementing DLSS and just going FSR2, no AMD blocking it like everyone (except MLID) is suggesting. Jedi survivor took ages to get DLSS support because of QA, heck, Fortnite, Epic's UE5 showcase, temp lost their DLSS support when they ported it to UE5 BECAUSE of QA.
4. It's a bad idea for this project to have to deal with support over all the bug reports for every single DLSS version upgrade that breaks something, it's a fairly well known issue that DLSS tends to get better at one thing, only to totally royally mess up something it did well before (hence the serious QA issues with DLSS, and why most of the time Nvidia has to shill out some resources to push their tech, or hope for often buggy mod support)

DLSS is not even close to being a low-hanging fruit, nor a priority given it's only for Nvidia users, and we already have a good enough upscaling tech thanks to AMD that also works for Nvidia users. Should Nvidia decide to open up DLSS, both in terms of licensing and remove the vendor lock, and should they figure out how to stabilize it, that's when it can be seriously considered for integration...

And before somebody tries to call me an AMD shill, I've ran nothing but Nvidia for the last 22 years of my life and I've only like 2 months ago switched for the first time in my life to AMD, as I was not keen on getting screwed over by Nvidia and their insane price premium and getting a significantly worse product (240€ for RX6600 vs 300€ for RTX3050 in my region at the time of purchase) I'm just going for what is the Better deal for me, and weighing in the risk of stuff breaking (big part of the reason why it took such an insane deal relative to Nvidia to make me make the switch was the risk of issues with my massive catalogue of software)

[MikeZTM]

@mrjustaguy This will benefit Intel iGPU most as Godot isn't a AAA engine and most game developer are not doing graphic heavy title with it. Most NVIDIA GPU that supports DLSS could already run those game good enough for relly high resolutions. But making XeSS DP4a available to Intel iGPU user will make their experience much better.

And no FSR2 is not "good enough" as it's clearly worse quality comparing to XeSS/MetalFX or DLSS. High quality XeSS/DLSS means those cards can drop down render scale to get better performance.

AMD isn't blocking FSR2 integration into streamline, that's a myth. They just aren't supporting it, but they cannot block it as they're releasing FSR2 under an MIT license.

That's even better, we could replace FSR implementation with a streamline and just use FSR though streamline then.

Starfield situation has nothing to do with this, ...

I'm not referring to the poor quality in general about Starfield. I'm talking about PC gamer angry about only supporting FSR2. It's clear AMD blocked DLSS in some game and this action makes Starfield super suspicious. And day 1 mod in DLSS/XeSS support makes it look even worse. Obviously anyone who said FSR2 was good enough in Starfield was called an "AMD shill" back then since the image quality is night and day different. I don't think offering XeSS/DLSS by the side of FSR2 and prevent game developer being called "AMD shill" is something that can be turned down.

DLSS is an absolute QA Nightmare.

It is, but same goes for FSR2. FSR2 is still unpredictable. All TAAU solutions are QA nightmare but we are not some AAA studio that have to make every single story goes through same QA procedure to make shareholders happy. I think we are doing pragmatic practice here instead of theoretically fixing everything.

It's a bad idea for this project to have to deal with support over all the bug reports for every single DLSS version upgrade that breaks something

It's quite simple -- we don't. DLSS/XeSS bugs are shared across all games including big releases. If they can live with it there's no reason we need to be nitpicking. Our audience want it and it does bring meaningful improvement then why should we block it just by it's not bug free?

Streamline benefit Intel and NVIDIA users. And down the line you need to have DLSS to fully utilize Switch Next. It will happen sooner or later. You cannot say FSR2 is good enough for a low power device that need the advantage of DLSS to use an even lower render scale. Same render scale using FSR2 will result in an artifact mess.

And open sourcing DLSS isn't helping anyone-- you have to rely on the ML model blobs. Even if NVIDIA provided full script code and training dataset for that model. you don't have a world's top 20 super computer to run the training anyway.

So model blob or model + some wrapper blob isn't a huge different. Especially when we have an open-source MIT licensed wrapper around that blob (plus Intel XeSS blob). Even if NVIDIA open the vendor lock, the fact AMD does not have anything more than 2xFP32 throughput is still limiting its quality. It will not help AMD user anyway and Intel have similar quality XeSS already so also nothing for Intel users. Streamline have support for everyone already and it's not like we are implementing DLSS and block XeSS.

The problem is you never look into NVIDIA and Intel solutions. FSR2 quality mode have more artifact than DLSS/XeSS performance mode. It's good enough only for AMD users due to that is most likely as good as possible for them. But Intel and NVIDIA user deserves a better option since this is under-utilizing their hardware.

[Zireael07]

If DLSS is known to be buggy, why integrate it?

[MikeZTM]

If DLSS is known to be buggy, why integrate it?

It definitely bring more benefits than being buggy.

Plus this is not only for DLSS, you got XeSS for free from integrating Streamline.

FSR is also buggy yet still got integrated. This is under-utilizing Intel and NVIDIA hardware.

[mrjustaguy]

I'm sorry, Devs supporting FSR but not DLSS is absolutely no evidence to suggest DLSS is blocked and that's the ONLY evidence that I've seen for it, while there's plenty of evidence that's been piled on against those accusations.

Look at it from their perspective. You have to QA only one tech instead of 2, so let's go with the one more people can use. Proof this is the case: Fortnite UE5 port temporarily removed DLSS support due to QA, Jedi survivor got it in a patch much later down the line, Starfield announced DLSS support incoming, Starfield's day 1 DLSS mod plagued by numerous image quality issues, AMD officially stated (around gamescom, a few months late from their initial poor quality responses) that they do NOT block competing technology, only ask for it to get a priority boost over others in the games they Sponsored.

It needs to be open source with a compatible license to Godot to be officially integrated, so yes Open source with compatible license is very important and just because AMD users (don't forget Intel here now.. they don't have specialized/optimized hardware for DLSS too) wouldn't benefit from DLSS now doesn't mean they couldn't in the future get proper hardware acceleration if were open sourced. To my knowledge only available Godot Compatible Upscaling tech is Nvidia's NIS which is just crappier FSR1 in every way, FSR1 which is already quite crappy as it's a spatial upscaling tech, and FSR2, and all the upscaling available that made sense is in Godot. I don't think XeSS is not compatible license, and DLSS is absolutely not a compatible license, so this discussion is pointless until that changes

[MikeZTM]

Streamline is MIT licensed so it is definitely compatible. Godot support DX12 on Windows so it's not avoiding all proprietary techs.

Intel does have dedicated hardware for XeSS. They have better int8 throughput and XMX unit for discrete GPUs.

For the QA thing. All machine learning AI stuff have this problem but you cannot avoid them forever. It’s bring more benefits than troubles and it should be up for game developers to decide not the engine.

Fortnite added DLSS back since they know with the cost of QA they still need this to meet the expectations from their audience.

FSR2 runs on NVIDIA and Intel but nobody wants that since they have better solutions that utilize their hardware for better quality and performance. It's like say you are building your game for PC and just include an Android simulator. It is an unfair treatment.

btw GPUs are full of firmware blobs and there’s no way to avoid that. Underutilization in the name of open-source is a bad excuse. Especially when vendor provided universal wrapper to work around the license.

You cannot say we only support open-source driver and crash for NVIDIA user on Linux.

[mrjustaguy]

streamline is MIT, but none of the tech that we'd need it for that we haven't implemented is compatible, That's the problem.

RDNA3 afaik has int8 too but I'm not sure how that's relevant.

I mean everything can be awful for QA, the problem with DLSS (maybe XeSS too, though never heard of this type of issue with that yet) is that every single version "Upgrade" often comes with a massive downgrade in some other region, which is a well known issue, and why techpowerup's DLSS dll library is so useful for tinkering, for switching out which version you are using to fix issues by going to older (or newer) versions for a game till you find one that works best. This simply isn't even nearly as true for any other tech, as there usually there is much less change going on from version to version, and where there's a massive change it's typically much better tested for regressions and such.

I know, hence Temporarily removed, but non the less removed due to QA, plenty of devs just gonna go "No thanks" to all that work.

DLSS-XeSS-FSR2 all have more or less identical performance (especially DLSS & FSR2), and better quality depends. I don't get that hypothetical at all, and even less how that's relevant.

They're called drivers, Anything that isn't optimized is underutilized and Godot does have intentional decisions that are "unoptimized" in the name of open source. The wrapper doesn't work around the license if you have no legal way to test if it works.

How does only Supporting FSR which everyone supports but not being able to support DLSS equate to making an experience unusable for an Nvidia user? Honestly this whole DLSS-FSR-XeSS discussion is kind of dumb, as in a blind test very very few users would be able to tell which tech they're using, and heck, many don't even know they're using any of those technologies.. So many times you'll hear people thinking that their Consoles are running their games at 4k, when they're running anywhere between 720p and 4k often upscaled using FSR2 these days, depending on the game and the DRS range..

[MikeZTM]

@mrjustaguy It's pretty clear the quality difference is night and day and FSR2 is barely better than not having FSR2 while DLSS/XeSS is much more detail due to less historical pixel wasted in the sample pass and less mistakes lead to less artifacts. At 4k performance mode DLSS have less artifact than quality mode FSR2.

This is not hypothetical, it's real and since you never really look into those techniques you never believe this is what happening. You are fooled by AMD's marketing since their int8 is 2xFP32 while Intel have XMX unit for 8xFP32 and NVIDIA have Tensor Core for 8x FP32 throughput. Those unit are dedicated unit just share power budget with shader (and some dispatch overhead) and are really efficient on running the complex ML kernel to improve quality.

DLSS/XeSS is a must have feature not something you could argue. This is basically unfair since AMD lacking such hardware is dragging NVIDIA and Intel users, especially for those who have weak GPU that could really benefit from those features. 1080p -> 4k is at least 2x performance for NVIDIA and Intel users. When using FSR2 you have to start from a much higher base resolution and sometimes that's still a pixelated mess.

Same performance for different result is already different performance.

It's always up to developer to choose if they want to enable these feature (and include the blobs) or not. You can not do the decision for them. And please stop opensource gating Streamline: Godot support DX12 and that's not open source anyway.

So many times you'll hear people thinking that their Consoles are running their games at 4k, when they're running anywhere between 720p and 4k often upscaled using FSR2 these days,

PS: If your mindset is let some (infact majority of them) PC player using a lower resolution while under utilize their hardware unit is fair then I don't know what keeps you working on Open-Source projects. Just tell everyone drop their resolution and call it a day. Most ppl will not notice 720p upscaled to 4k anyway right?

I hate to say this but if any reasonable feature proposals have to become a drama before getting accepted then it will be a huge waste of time for all of us. This feature is benefiting Intel and NVIDIA users by giving them almost 2x performance bump and ready for Switch Next. You shouldn't deny something just because it does not benefit you. You made the decision going AMD without knowing how important this feature could be is your mistake and you should not let others suffer just for that. I feel bad for the pricing in your region and over hype of Frame Generation, and I never think 2x performance for a 3050 can match 6600 after all. But 2x is still 2x and for people with a 3050, that would be a god send and they can enjoy some light weight title in 4k--especially for those with a laptop and high density screen.

As I'm running a 4090 this feature will absolutely not benefiting me from an end user prospective. But hey we are making games for others and why would we intentionally make NVIDIA and Intel audience un-optimized to match AMD? Back when NVIDIA have bad DX12/Vulkan performance, will you decide to keep using DX11/OpenGL until they catch up with AMD?

[mrjustaguy]

I happen to have been testing FSR2 integration in Godot, and I can say right away, I'd rather play at 720p FSR2 to 1440p vs 1080p bilinear to 1440p, so clearly it's better compared to just dropping native res, though I'd only ever use DLSS/FSR/XeSS/TSR/TAAU only as a last resort anyhow.

Your assumption is wrong. I've been following these techniques since they came out. Also how am I fooled by AMD's marketing if I stated they support something that they do, and it's just not as good as the competition which I never claimed it was? If I were really fooled by marketing I'd have gone for the 7600 instead of the 6600.

I can argue that DLSS/XeSS is not a must have feature. Argument is to hell with Upscaling and optimize your games. I'm never said DLSS/XeSS arent generally visually superior, I'm just saying that the gap isn't that large and that FSR2 is a good Compromise. Supports like every GPU from Maxwell+ and GCN+, Does a fairly good job, and is fairly straight forward and compatible with Godot.

Yes.

DX12 is a requirement for Platform Support (Console) while DLSS and XeSS are not a requirement for ANYTHING. And by all means, if you want go ahead and implement Streamline into Godot. It'll get accepted or rejected on it's merits, like anything else. My point is that there is little point in wasting time of the people who are capable of implementing it and have other things to work on.

I just stated a fact, my mind set is to hell with any upscaling, but the point I made is that plenty of people just don't care as it's good enough to be successfully fooling them. Also you are ALWAYS under utilizing your hardware, and there's always tradeoffs to be made between things like - Simplicity, Performance, Quality, Flexibility, Size, Compute Usage, Memory Usage, Maintainability. You Cannot get the best of everything.

You started dramatizing this whole thing really, most of the time the discussion is kept civil though there are some proposals that can be controversial. I'm not denying Nvidia and Intel users something because it doesn't benefit me. They've done the work to make it hard for Godot to get proper support... I also didn't make a mistake switching to AMD, and it remains to be seen but so far it's been one of the best decisions I've made in the last couple of years by far.. and you telling me that one feature is important and that I've made a mistake based on your are using your stuff for without consideration for what My use case is.. well a bad way of assessing things. I've examined all the options and their pros and cons. I picked the RX 6600 because of Adrenalin software (Per app Display setting overrides, an actual feature I'm using all the time now that Nvidia doesn't support) and price-perf was better vs Nvidia no matter what way you slice it, even if you compare Native AMD vs DLSS Nvidia as if it were apples to apples, which I don't, I want Upscaling as far away from my gaming experience as possible which is already making DLSS a null feature for me, if it weren't for the poor Game support (I have 2 games that Support DLSS right now, and they ain't very demanding, every actually demanding game I've got has no Upscaling support whatsoever) To 3050 users any upscaling would be a godsend if they're trying to run at 4k, it'd just be better if they had DLSS, but FSR will get the job done too, so...

Optimization is a relative term. What are you optimizing for? Godot is Optimizing for ease of use and maintaining, and highly portable design over Performance, unless the Performance difference is Massive, which here isn't the case. No one is doing this to match AMD, and I'm honestly baffled by how you got to that conclusion. If you had made this comparison with Ray Tracing I'd have understood the point.. for DLSS support this comparison makes no sense to me. Everyone Equally benefits from FSR2.. But to keep to the comment, I'd go with whatever suits me and my goals best, naturally, which would be Vulkan due to being less limiting. I'd also ahem ahem, Go with Ray Tracing if it were viable now (as it'd be much simpler to make good graphics with it instead of hassling with poorly faking things with Raster), It's just not to any extent that makes sense to me, and it's sadly a tech that is still a decade from actually being usable IMHO.

[MikeZTM]

@mrjustaguy I clearly claimed FSR2 is better than not having it. And you don't need to bring up linear scaling to convince me. I'm fully aware of that and never said we shouldn't include FSR2.

I still hate to call FSR2/DLSS upscaling due to they are not doing any upscale anyway. Since you should have already got background about FSR2, you should already know they are more resembling a downscale procedure. FSR2 is no different than DLSS in that front and it's important as an optimization method due to free 2x performance.

I'm not saying anyone should cover their suboptimization with DLSS and usually those are just excuse as DLSS could not help them for the frame spikes. You have to have a stable game to begin with to benefit from these techniques. When they making up excuses it does not matter what is involved in those claims.

FSR2 is just like a variant of DLSS with less quality. But this quality difference is making DLSS/XeSS not a tradeoff of image quality anymore. Quality mode DLSS can match downscaling image by SMRE/PSNR. Not saying that measure is perfect, but good enough for a comparison.

Plus this decision put game developer in danger of being called "AMD shill", since it is quite clearly benefiting AMD by suboptimizing Intel and NVIDIA.

As always, I'm not saying this feature should be there next week. It should be put in backlog and got picked up sometime down the line, maybe early next year or so.

[mrjustaguy]

you said it's barely better than not having it, that's what I commented on.

Upscaling is exactly what it's doing if you're not running Native by definition as it's adding pixels that didn't exist in the image before. and if it were free 2x performance, there'd be no reason to not use it and you wouldn't care which one you're using for that reason, but it's not as image quality suffers the lower you go.

Upscaling shouldn't be used for that, totally agree there, However excuses matter if they're legit. Like for example I'm making a game on an IGPU that has no RT support, my excuse for not making a AAA blockbuster Path traced masterpiece is that I don't have the ability to make it.

I cannot say I understand what you're trying to say here.

I don't see any game dev being called an Nvidia shill because they only support DLSS, I do however hear it a ton about AMD, and occasionally even Intel which I personally find a bit funny.. and besides, smaller devs got different expectations vs AAA studios that have the resources to do this, or when they don't support something that their Engine does like was the case with Star Wars.

[MikeZTM]

Wait a second. You do know that FSR2/DLSS is cherry-picking pixels from historical frames to fill in the gap between lower render resolution and output resolution right?

They are not magickly generating pixels and with good enough frame rate the result can be quite good or even better than native due to more pixels got reused and becomes super sampling.

[mrjustaguy]

yeah. and that still fits in the definition of Upscaling.

I know it's not magic.. though DLSS 1 was just generating pixels based on input data as if I remember right it didn't take temporal data, just had to be trained on all the scenes at ultra high res, which is why it had such insanely horrible artifacts and was just AI doing educated guess work, though I may be wrong about this, as I didn't bother going into DLSS 1 when It was indisputable garbage that's worse than simple interpolation and sharpening (essentially NIS and FSR1)

[MikeZTM]

You are absolutely correct about DLSS 1 as far as I know. CAS beat DLSS1 in most cases, as DLSS1 is just an oil paint filter 99% of the time.

I still don't think that's Upscaling when you have more than native pixels to work with. Those pixels got wasted in traditional render and reusing them is just a clever way of render -- such innovation was always happening though out the 3D gaming era.

[mrjustaguy]

by dictionary definition it is Upscaling, but Reconstruction works too.

[MikeZTM]

Anyway I still think Streamline is worth the consideration as it really could help low end NVIDIA /Intel GPU or iGPU. And the work left here is most likely related to devops instead of heavy engine changes since the FSR2 support is already exist.

Reconstruction sometimes give you quality boost compare to native. Especially when you have to enable TAA.

This will pave the way for next Switch enablement and enabling Intel iGPU user to play godot engine games at much higher performance (expecting 2x with quality improvement). Since native Metal support is on the roadmap, MetalFX is obviously coming with that or even before that if MoltenVK support it somehow. I think bring in NVIDIA and Intel optimization from a open-source wrapper is pretty much needed.

[ikonnow]

Hello, I'm interested in this proposal and I wonder what is the current status of it. I noticed that in the SDK v3.5, support for Linux kernel 2.6.32 and newer is mentioned (https://developer.nvidia.com/rtx/dlss/get-started#sdk-requirements). Does this mean that Godot will be able to use DLSS on Linux platforms soon? Thank you for your work and attention.

[Calinou]

Hello, I'm interested in this proposal and I wonder what is the current status of it. I noticed that in the SDK v3.5, support for Linux kernel 2.6.32 and newer is mentioned (developer.nvidia.com/rtx/dlss/get-started#sdk-requirements). Does this mean that Godot will be able to use DLSS on Linux platforms soon? Thank you for your work and attention.

As mentioned above, DLSS 2.x and later has had native Linux support for a long time (even if no Linux-native games currently support DLSS 2). It's also possible to use DLSS on Linux via Proton thanks to Proton's NVAPI support[^1]. The issue is that we can't integrate proprietary libraries in core, so it must be a community extension or engine fork. Right now, this will likely require an engine fork until more of the rendering engine is exposed to extensions. The engine fork can distribute precompiled editor and export template binaries on relevant platforms (Windows/Linux) to make it easier to use.

[^1]: This requires a launch option, as Proton will pretend to be using an AMD GPU by default for compatibility reasons.

Similar concerns apply to XeSS, although it doesn't even have native Linux libraries available (it can still be used in Proton).

Developing community extensions or engine forks doesn't require going through the proposal process. Someone can already start working on it on their own :slightly_smiling_face:

[BuyMyMojo]

With the addition of The Compositor in 4.3 would it be viable to create extensions now instead of an engine fork or would the compositor still need to be expanded in the future to support this?

[mrjustaguy]

There is no reliable way exposed to properly control camera jitter outside of core atm. https://github.com/godotengine/godot-proposals/issues/2779#issuecomment-2316081120 once that gets resolved I don't see any more problems