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:
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.
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.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.
ICYMI: 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.
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.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.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.
Last edited by slaapliedje on 3 April 2022 at 3:52 pm UTC
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.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
Last edited by x4mer on 31 March 2022 at 10:54 pm UTC
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.There was an attempt to add FSR to Proton, it was rejected: https://github.com/ValveSoftware/wine/pull/116
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.Blink, the Chromium renderer, is a fork of WebKit.
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.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.
Sounds like Gamescope will be coming to the new UI once it becomes available in places besides the Deck.
Apples problem was more that they really didn't know how to collaborate at first
They never learned; that's why Google forked Webkit to Blink. For a very recent example: they drove away the creator of Swift, who, although he had left Apple 5 years ago, was still volunteering his time to contribute to the project.
ICYMI: 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.
Wayland works on the latest greatest GNOME and KDE but mostly the rolling distros have it atm
License doesn't prevent poor community management and it's not possible convert company to full open source contributor. Having license options out there helps ease the transition though.This is what I was pointing out recently about log4j. People pointed out terrible thibgs in the code years ago... but no one wanted to fix it until exploits popped up.
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.