Confused on Steam Play and Proton? Be sure to check out our guide.

Steam Play Proton could get direct support for NVIDIA Image Scaling

By - | Views: 14,889

An engineer from NVIDIA has put up a Pull Request on the official Wine repository that Valve uses for Proton, suggesting a rather fun new feature be added.

Developer Eric Sullivan put up the Pull Request titled "Support for NVIDIA Image Scaling", if accepted it could mean a future release of Proton would enable users (of any GPU vendor - it's a simple shader) to upscale applications to the current display resolution with NVIDIA Image Scaling. The idea of that sounds pretty exciting, as the more options it supports the better.

While it's true developers can add options like this officially into games like what already happens with NVIDIA DLSS, AMD FSR and other tech, this is much more of a brute-force approach to give Proton the ability to do it to any game, (a bit like how you can do FSR on the Steam Deck).

From the pull request:

This pull request adds an option to fshack to upscale applications to the current display resolution with NVIDIA Image Scaling. It can be enabled by setting the WINE_FULLSCREEN_UPSCALER environment variable to "NIS". The NIS upscaler also supports using FP16 storage by setting WINE_NIS_UPSCALER_USE_FP16 to 1.

It should go without saying but I will anyway: this might not be accepted, so don't get overly excited just yet.

ICYMI: NVIDIA are also working with Valve to get Gamescope working on their drivers.

Article taken from GamingOnLinux.com.
23 Likes
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
14 comments
Page: 1/2»
  Go to:

dec05eba 31 Mar
One concern I have with patches being pushed to corporate forks rather than upstream wine is the situation we had with KHTML and WebKit, where Apple managed to hijack the project. Wine is licensed under LGPL rather than GPL which was the exact same situation with KHTML. LGPL allows you to add proprietary components later as well, and then slowly change license by changing part by part into different licenses as you replace the code.


Last edited by dec05eba on 31 March 2022 at 3:45 pm UTC
randyl 31 Mar
Quoting: dec05ebaOne concern I have with patches being pushed to corporate forks rather than upstream wine is the situation we had with KHTML and WebKit, where Apple managed to hijack the project. Wine is licensed under LGPL rather than GPL which was the exact same situation with KHTML. LGPL allows you to add proprietary components later as well, and then slowly change license by changing part by part into different licenses as you replace the code.
Apple didn't hijack anything. That's how the license and forking works. Upstream is free to pull from a fork as well. People are free to use the fork or the original project. Sometimes that works out poorly for the original project, but there are reasons for that (see Open Office vs Libre Office).

Licenses work exactly how they're written, not how people feel the "spirit" of it should work. Every license has its strength and weaknesses. This is a good pull request that both Proton and the WINE project can benefit from.
melkemind 31 Mar
QuoteICYMI: NVIDIA are also working with Valve to get Gamescope working on their drivers.

Did they even get Wayland working with their drivers? Last time I looked, it was a no-go in KDE. I admittedly haven't looked in a while though.
slaapliedje 31 Mar
View PC info
  • Supporter Plus
Quoting: randyl
Quoting: dec05ebaOne concern I have with patches being pushed to corporate forks rather than upstream wine is the situation we had with KHTML and WebKit, where Apple managed to hijack the project. Wine is licensed under LGPL rather than GPL which was the exact same situation with KHTML. LGPL allows you to add proprietary components later as well, and then slowly change license by changing part by part into different licenses as you replace the code.
Apple didn't hijack anything. That's how the license and forking works. Upstream is free to pull from a fork as well. People are free to use the fork or the original project. Sometimes that works out poorly for the original project, but there are reasons for that (see Open Office vs Libre Office).

Licenses work exactly how they're written, not how people feel the "spirit" of it should work. Every license has its strength and weaknesses. This is a good pull request that both Proton and the WINE project can benefit from.
In the case of webkit, it sure would be nice if the Gnome devs would take the Safari / Apple improvements and make it a better browser. Firefox is getting terrible. Though Epiphany would then need a Windows / Mac port too.


Last edited by slaapliedje on 3 April 2022 at 3:52 pm UTC
dec05eba 31 Mar
Quoting: randyl
Quoting: dec05ebaOne concern I have with patches being pushed to corporate forks rather than upstream wine is the situation we had with KHTML and WebKit, where Apple managed to hijack the project. Wine is licensed under LGPL rather than GPL which was the exact same situation with KHTML. LGPL allows you to add proprietary components later as well, and then slowly change license by changing part by part into different licenses as you replace the code.
Apple didn't hijack anything. That's how the license and forking works. Upstream is free to pull from a fork as well. People are free to use the fork or the original project. Sometimes that works out poorly for the original project, but there are reasons for that (see Open Office vs Libre Office).

Licenses work exactly how they're written, not how people feel the "spirit" of it should work. Every license has its strength and weaknesses. This is a good pull request that both Proton and the WINE project can benefit from.
You didn't get my point. Thats exactly what LGPL enables. This whole process is not possible with GPL. Its specifically about LGPL. The project is replaced and then proprietary components are added after the project is hijacked. Yes, Im intentionally using that word. Apple intentionally delayed releasing LGPL code while taking others LGPL code and also adding proprietary components to give them a "market" advantage and force users to use their product because websites became dependant on the proprietary extensions. That is intentional hijacking.
Anza 31 Mar
Quoting: randyl
Quoting: dec05ebaOne concern I have with patches being pushed to corporate forks rather than upstream wine is the situation we had with KHTML and WebKit, where Apple managed to hijack the project. Wine is licensed under LGPL rather than GPL which was the exact same situation with KHTML. LGPL allows you to add proprietary components later as well, and then slowly change license by changing part by part into different licenses as you replace the code.
Apple didn't hijack anything. That's how the license and forking works. Upstream is free to pull from a fork as well. People are free to use the fork or the original project. Sometimes that works out poorly for the original project, but there are reasons for that (see Open Office vs Libre Office).

Licenses work exactly how they're written, not how people feel the "spirit" of it should work. Every license has its strength and weaknesses. This is a good pull request that both Proton and the WINE project can benefit from.

Based on what I quickly read about the history of Webkit, Apples problem was more that they really didn't know how to collaborate at first, which made collaboration between Webkit and KHTML project really hard. They fixed lot of issues later and while Safari is more of an open core project, the Webkit engine is usable outside Safari. It just isn't very popular, people are mostly building browsers based on Chromium instead.

In case of Safari, GPL wouldn't have fixed the issues as such. With GPL, Apple might have just looked elsewhere and if there wouldn't have been usable engine out there for their use, they might have just developed totally proprietary engine.

License doesn't prevent poor community management and it's not possible convert company to full open source contributor in short term. Having license options out there helps ease the transition though.

Long term everything is possible though. Microsofts path would be something like this: first paint open source as enemy, but secretly use BSD code. Then experiment with licenses that are not really open source, but people get to look at the code. Latest phase seems to be that when it suits Microsoft, projects appear in Github with open source license. Not necessary GPL, but still open source. I checked and Windows Terminal is licensed with MIT license.


Last edited by Anza on 3 April 2022 at 8:24 pm UTC
x4mer 31 Mar
Glorious Eggroll version of Proton since V6.16(?), already has AMD FSR routines patch for fshack. NVidia now trying to get their routines in to main Proton instead of the AMD ones people have already been using for months via GE.


Last edited by x4mer on 31 March 2022 at 10:54 pm UTC
Egonaut 31 Mar
Quoting: x4merGlorious Eggroll version of Proton since V6.16(?), already has AMD FSR routines patch for fshack. NVidia now trying to get their routines in to main Proton instead of the AMD ones people have already been using for months via GE.
There was an attempt to add FSR to Proton, it was rejected: https://github.com/ValveSoftware/wine/pull/116
CatKiller 31 Mar
View PC info
  • Supporter Plus
Quoting: AnzaThey fixed lot of issues later and while Safari is more of an open core project, the Webkit engine is usable outside Safari. It just isn't very popular, people are mostly building browsers based on Chromium instead.
Blink, the Chromium renderer, is a fork of WebKit.
Anza 31 Mar
Quoting: CatKiller
Quoting: AnzaThey fixed lot of issues later and while Safari is more of an open core project, the Webkit engine is usable outside Safari. It just isn't very popular, people are mostly building browsers based on Chromium instead.
Blink, the Chromium renderer, is a fork of WebKit.

Yes, I'm well aware. Just didn't include that fact in already long rant.

I'm not sure how much they still share code though. Probably not much.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: Liberapay or PayPal.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.