Every time I see some feature of Windows I don't have, I ask myself: if I paid for Windows, would I be satisfied with the product?

The answer is always no. With the amount of bugs, ads and telemetry Windows with all it's features would only appeal to me as a "free" product.

That said, I am so glad I can use Linux for free and only donate when I am able to.

By the look of things, this feature is more of a demo anyway. It comes with caveats like specific API requirements (DX11) and the mouse-movement based resolution reduction requires a presence of a whitelist because it would potentially cause weird issues in games where mouse-movement doesn't have the same effect as in FPS games and the like.

Honestly, this feature seems like something that shouldn't be on the driver level at all, but should be a feature in games themselves on game engine level. Particularly since games will in the future be more responsible for how their rendering works (thanks to lower level APIs like Vulkan), which makes tapping into rendering from outside more prone to errors.

Quoting: SamsaiBy the look of things, this feature is more of a demo anyway. It comes with caveats like specific API requirements (DX11) and the mouse-movement based resolution reduction requires a presence of a whitelist because it would potentially cause weird issues in games where mouse-movement doesn't have the same effect as in FPS games and the like.

Honestly, this feature seems like something that shouldn't be on the driver level at all, but should be a feature in games themselves on game engine level. Particularly since games will in the future be more responsible for how their rendering works (thanks to lower level APIs like Vulkan), which makes tapping into rendering from outside more prone to errors.

Chill was also limited to begin with. But now it supports most games (DX9-12 and Vulkan). Whatever case though It would have been nice if these features were made available for us too. But still a while before we can get them, marketshare is still slim.

Last edited by Linuxwarper on 3 Aug 2020 at 7:11 pm UTC

I can understand that it may feel like Linux is limited in regard to these kind of features. But I will argue that this is by design and is actually a strength of Linux.

Linux is built around principles of consistency, interoperability, and standardization. That is why every part of the system has clearly defined boundaries, and that is the reason why you can configure wired and wireless networks, and a bunch of different VPN's through a consistent interface in Network Manager, why different graphics drivers work with the same Mesa libraries, why you can just remove your hard-drive from an Intel Core i7 system with embedded graphics, and boot it on an AMD Ryzen system with Radeon graphics, and it would just work, etc.

On Windows, on the other hand, almost everything requires some sort of non-standard system tray agent. Intel has their own manger, Lenovo, HP would run their own agents to do whatever they are doing. They take control over a large portion of the system, and there is no clear distinction between what is a user-space application, and what is a kernel driver. These are very often mutually exclusive and trying to install multiple would most likely majorly fuck up your system. Unfortunately many of the "smart" gaming features fall into this category.

In Linux such gimmicks that only work for some specific driver, and/or driver/software combination are generally frowned upon, because it is more about playing nice together, than one single company trying to push real or imaginary competitive edge.

If these features become standard, like e.g. an official Vulkan extension, you can bet they will eventually be implemented.

Quoting: LinasIf these features become standard, like e.g. an official Vulkan extension, you can bet they will eventually be implemented.

You think features like DLSS, Chill and Radeon Boost will become standard? The issue why they are often not available on Linux is because they are not standard.

The issue isn't that Linux's design is lacking. It is that Linux is lacking features that would be nice to have. It took AMD a long time to support FreeSync on Linux. Linux is definitely limited when it comes to the features I've mentioned. I highly doubt you will see Nvidia support Linux with DLSS as well as on Windows if at all.

This isn't enough to make me want to switch back to Windows though, but I think it's important to acknowledge this issue.

Last edited by Linuxwarper on 5 Aug 2020 at 6:17 pm UTC

Quoting: LinuxwarperYou think features like DLSS, Chill and Radeon Boost will become standard? The issue why they are often not available on Linux is because they are not standard.

Not as such, no. But under the branding there is usually hiding some more standard feature, like a thermal interface, or some image processing pipeline. These could totally become standard.

Quoting: LinuxwarperThis isn't enough to make me want to switch back to Windows though, but I think it's important to acknowledge this issue.

Yes, of course. But implementing these in the Linux graphics pipeline is a lot of work, because it is very different from Windows. It is a lot of work on Windows as well, but the vendors can do this, because they can use it as a competitive edge against other vendors. We are just too small of a market for them to bother with what is anyway a completely optional feature.

Quoting: LinuxwarperI highly doubt you will see Nvidia support Linux with DLSS as well as on Windows if at all.

I don't think there's any reason why they wouldn't, actually.

Should Bethesda, say, since they like themselves a bit of Vulkan, suddenly decide that they want to release their games on Linux, and they want to use DLSS, I think Nvidia would be happy to make that happen.

They're allergic to the GPL, which is why they haven't done it for their own game, Feral have got no reason to only target half of a very small market by spending time translating features that would only work on Nvidia cards, and the Wine/DXVK/VKD3D folks have the additional barrier that it's putting support for proprietary stuff in their open source project, but, if one of Nvidia's existing partners wanted it they'd do it, and it probably wouldn't be that much work.

As long as they get to keep their toys in a black box and behind an NDA they want people to use them. It would be a library along with the driver that provides those functions. Someone just needs to give them a reason to compile it.

Quoting: LinasLinux is built around principles of consistency, interoperability, and standardization.

...through CLI only. Also, the numerous distros out there (and the different kernel versions) make it more difficult to aim for a "standard". Even with Snap (sorry, couldn't resist :tongue:).

Quoting: furaxhornyx

Quoting: LinasLinux is built around principles of consistency, interoperability, and standardization.

...through CLI only. Also, the numerous distros out there (and the different kernel versions) make it more difficult to aim for a "standard". Even with Snap (sorry, couldn't resist :tongue:).

I did not mean it as in all Linux distributions are consistent or even that it is completely consistent within itself. I meant it more at the lower level, the architecture of the system.

For example Linux kernel drivers, DDX (Xorg) driver, and Mesa libraries have their well-defined scope to produce a consistent experience. You can switch out Xorg with Wayland while keeping the kernel driver, and Mesa exactly because of this.

Now let's say you want to make Mesa render at a lower level-of-detail based on the GPU temperature. A naive implementation could be reading the temperature of the GPU in the Mesa library, and adjusting LOD based on that. Except that Mesa is a user-space library and the thermal interface is in the kernel, so suddenly you are breaking responsibility boundaries, and introducing dependencies between components. And different GPU's may report the temperature differently, or not at all. Also the thresholds are different depending on the model, so you need to be able to configure this somehow. Doesn't take that much to end up with a total nightmare of a system where everything is interconnected, and not portable between vendors.

Now the previous example may not be very technically accurate, but that is what you can do when you own the entire stack and don't give a crap about interoperability. Like, you know, on Windows.

Quoting: LinasNow let's say you want to make Mesa render at a lower level-of-detail based on the GPU temperature. A naive implementation could be reading the temperature of the GPU in the Mesa library, and adjusting LOD based on that.

There's a much simpler explanation for why Radeon Boost in particular isn't something we'll ever see.

It just does not work.

It's limited to a whopping total of 8 games. Eight. Why? Because with the way modern computer graphics work these days, you can't just hook the API and lower render target resolution or viewport size, you'd break all sorts of post-processing effects and lighting passes and whatnot in the process. So basically, AMD have to explicitly implement per-game hacks that set the appropriate knobs (viewport size, shader parameters, compute shader workgroup counts etc.) for every single game they want to support.

Not to mention that the overall approach is just garbage. I tested it with SotTR back in the day when the driver that heavily advertized the feature came out and really just leads to janky camera controls, since rapidly changing frame times isn't something that games are particularly fond of. Guess why you pretty much never hear anybody talk about this anymore? Yeah, nobody fucking uses it.

You know what does work reasonably well in practice? Games adjusting rendering resolution dynamically by themselves to hit a desired frame rate. It's getting increasingly common and should be a viable way for the 4k crowd in particular to enjoy their games at reasonable quality and performance levels without having to buy a 2080 Ti. And all of that without AMD making an even bigger mess out of their Windows driver package than it already is.

Last edited by YoRHa-2B on 6 Aug 2020 at 2:57 pm UTC

Quoting: CatKiller

Quoting: LinuxwarperI highly doubt you will see Nvidia support Linux with DLSS as well as on Windows if at all.

I don't think there's any reason why they wouldn't, actually.

Should Bethesda, say, since they like themselves a bit of Vulkan, suddenly decide that they want to release their games on Linux, and they want to use DLSS, I think Nvidia would be happy to make that happen.

They're allergic to the GPL, which is why they haven't done it for their own game, Feral have got no reason to only target half of a very small market by spending time translating features that would only work on Nvidia cards, and the Wine/DXVK/VKD3D folks have the additional barrier that it's putting support for proprietary stuff in their open source project, but, if one of Nvidia's existing partners wanted it they'd do it, and it probably wouldn't be that much work.

As long as they get to keep their toys in a black box and behind an NDA they want people to use them. It would be a library along with the driver that provides those functions. Someone just needs to give them a reason to compile it.

But you won't see Nvidia take the iniative to make DLSS work through Proton or natively. That's my point. They may do it when Linux market grows but then so will all other actors too when they see it's beneifical. They won't do it for time being or probably not in a year or two.

Quoting: YoRHa-2BNot to mention that the overall approach is just garbage. I tested it with SotTR back in the day when the driver that heavily advertized the feature came out and really just leads to janky camera controls, since rapidly changing frame times isn't something that games are particularly fond of. Guess why you pretty much never hear anybody talk about this anymore? Yeah, nobody fucking uses it.

You know what does work reasonably well in practice? Games adjusting rendering resolution dynamically by themselves to hit a desired frame rate. It's getting increasingly common and should be a viable way for the 4k crowd in particular to enjoy their games at reasonable quality and performance levels without having to buy a 2080 Ti. And all of that without AMD making an even bigger mess out of their Windows driver package than it already is.

I don't have reasons to doubt you but if it's as you say, then AMD is pretty stupid for persuing such a feature. It seemed like a good idea but when I realize the fps would go up alot I no longer thought it as useful. Even if you could adjust to fps going up, it would surely be somewhat annoying.

Hopefully we will see more games with dynamic resolution.