Source is this video:
Windows Was The Problem All Along - Dave2D
We could obviously compare performance between windows and steamOS before on the steam deck, or between windows and Bazzite on other handhelds. But this is the first time we have had official windows and SteamOS builds for the same hardware.
literally the next line
I really hate the dismissal of the heavy lifting proton does. Proton is what makes gaming on Linux so great. So many native linux games perform worse on Linux vs their windows counterparts. Then again, I’d expect nothing less from Dave2D
I mean, yeah, but if Proton is doing an absolutely flawless job, then it has 0 performance penalty compared to Windows. All the actual gains still do come from Linux having less overhead. So, both are true, that Proton is killing it and that the gains come from Linux.
DXVK (which also runs on windows) alone gives you a huge performance benefit. Playing world of warcraft on windows I’ll see about a 30% reduction in CPU usage and higher performance.
Proton doesn’t just get you to almost matching Windows’ performance. Proton easily outperforms windows even on higher end hardware where windows bloat isn’t a concern.
While proton enables that, that’s still just vulkan outperforming DirectX.
So technically proton isn’t improving performance here, it’s just allowing the game to run on better performing systems (like Linux and vulkan).
It’s just Vulkan outperforming DirectX by translating DirectX to Vulcan. If you’re comparing the default experience with Windows and Linux, how can you say Proton isn’t technically improving performance? What would you call that if a performance increase is caused by running through Proton?
As pointed out higher up this thread DXVK and Vulkan also work in Windows (without Proton) were they give performance improvements.
Further, it’s perfectly possibly to run Windows games via DXVK and Vulkan in Linux without Proton - just use plain Wine (of which Proton is a branch) instead - and you also get the performance improvements (certainly that’s my perception in my system since I tend to get my games from GoG instead of Steam when available and thus run them via Wine instead of Proton).
So that’s at least two situations were the performance improvements are present without Proton, hence you cannot logically claim they’re due to Proton, even indirectly.
Logically the place most likely to yield performance improvements is the full implemention of a rendering stack directly on top of the hardward which even has its own architecture - Vulkan - since there’s a lot more room to improve usage of hardware resources at that level, though things like pre-conversion and caching of Vulkan shaders from DirectX shaders, which are done at a higher level (Proton or DXVK), can also improve performance.
It’s possible that Proton itself is delivering some performance improvements (for example, via the trick of, pre-converting shaders from DirectX to Vulkan before game start, uploading the generated shaders to the Steam servers and then other users just download the converted shaders and do not require that step, which should speed up game start tough I have at least one game were it actually can slow down A LOT game start because the generated shaders are massive) versus solutions using DXKV + Vulkan without Proton, but that’s not really enough to sustain a claim that the performance improvements are mainly thanks to Proton in the face of also seing the performance improvements when Proton isn’t there.
Except these tests were almost certainly being run on SteamOS using WINE with Proton. We can’t know what the numbers would be with any other setup without doing it. Would a Protonless DXVK for WINE run just as well? We can’t know from these figure.
Also, Proton does not require running through Steam. I play Epic, GoG, and otherwise sources games with Proton not through Steam all the time. It’s also more than just DXVK. That’s a big part of it though.
No one is arguing that DXVK isn’t important or anything like that. They’re just saying Proton is a piece of this, which includes DXVK. I don’t know why you’re arguing.
Yeah its wine/proton and linux together. Wine/Proton efficiently handles translating the Windows programmes API calls into POSIX calls while Linux seems to offer a lower OS overhead so there is more system resource available for the games.
I do think Proton gets a little too much credit. Its wine plus faudio, dxvk and other open source projects combined. Proton is great but it is standing on the shoulders of giants.
Agreed. Proton is important as a bit of an “iPhone moment” where all this tech comes together in a way where non-techies “get it” in the sense where they understand why it’s useful, even if they’ll never bother to learn the details of why or how.
Why? Valve has been sponsoring all these projects for a really long time. While wine existed before that, it wouldn’t be anywhere near the shape thats its currently in because gaming was not its main focus. There have been loads of gaming bugs and sharp edges that have been around wine for a long time until Valve put in the money and devs to fix them.
What does proton do?
I only vaguely understand it as “thing that makes game playable on other thing.”
(And also I have six versions installed on my steam deck whydoIneedsixofthese?)
Proton is the compatibility layer that valve makes that lets you run games on Linux. Proton uses DXVK a program that converts Direct X API calls (windows only) to Vulkan API calls (runs on anything). DXVK alone gives you huge performance benefits (especially on older DirectX 11 and older games) and you can run it on windows.
Proton gives you a ton of other tools that can make huge performance differences.
Hopefully not a dumb question: If Vulkan runs on anything, assuming their game isn’t a Windows (Xbox?) exclusive, why don’t more people program their games to use Vulkan instead?
It’s becoming more common, but it mostly comes down to available tooling. At this point all three of the big game engines have a Vulkan backend available, but that’s a fairly recent development. And if a developer isn’t using a game engine, writing their own openGL renderer is easy, and writing a Vulkan renderer is a nightmare.
Also a lot of old proprietary game engines were written either specifically for DirectX or additionally for DirectX because in the olden times it was the most advanced and compatible rendering software.
Then, those developers move forward in time to work on other engines and focus primarily on DirectX because it’s still good, compatible, and it’s what they know best. OpenGL languished and it took a while for Vulkan to come out, catch up, and standardize their API.
That my friend, is entering operating system politics.
But the TLDR is: resistance to change, lack of support, bribery, a combination of all 3, features, and much much more!
Vulkan is designed to be closer to the metal than something like DirectX 11 or OpenGL, which makes the API more explicit and difficult to use. This means it requires a great deal more care to use properly. And to complicate matters more, subtle bugs that are very difficult to debug are very easy to introduce.
But, this applies mostly to devs who build their own tech. Most of them these days are just using 3rd party engines like Unity or Unreal, so it comes down to whether or not the person making the game decides to check the box to use Vulkan and just how good those render backends are. Engine developers of 3rd party tech have to build their stuff to be as generic as possible. That’s likely gonna add a lot of bloat that might not be fully optimized for every game developer’s use case.
TLDR: It’s tough and time consuming for someone writing it themselves. And for the ones who aren’t, they’re having to place a lot of trust in a renderer that is probably a black box and might be buggy/slow.
Because DirectX is more than a graphics API.
https://en.m.wikipedia.org/wiki/DirectX
A fair amount of what used to make DirectX an everything API has been deprecated, but if you are already using Windows stuff for networking and audio, then you may as well use the graphics APIs too.
I’ll add for completeness that vkd3d-proton handles DX12 titles, and of course OGL and Vulkan are supported natively.
Most simply put, it’s a layer that allows a computer program expecting windows to run on Linux. It isn’t emulating anything, just sorta like translating.
Think of it like a language. Windows speaks English, so a program expects to talk in English. But let’s pretend like Linux talks Spanish. Proton translates the English commands to Spanish for Linux to understand and execute, and then Proton converts the responses back to English for the program.
The big thing though about Proton is that it’s not an additional translation/emulation layer. It doesn’t translate into Spanish for Linux, as that would be slow, it makes Linux talk English.
So in your example, imagine you, the English speaking program, want to catch a taxi in Madrid/Linux but all taxi drivers speak only Spanish. An emulation layer would be “translating”, so you would have an additional guy in the taxi that you could talk to that talks to the Spanish driver. Proton is not that, it’s an English-speaking taxi driver.
Proton uses Wine, which is a Windows system call API translation layer for Linux. In other words, it translates commands for the Windows kernel into calls for the Linux kernel.
So it’s kind of an emulator and kind of not, but regardless the metaphor of a translator is fine. As a lightweight translator, you might say it’s like using Google Translate on your phone to translate back and forth quickly and automatically, rather than having a person in the middle who needs to think about it.
In Software Design terminology, Wine and DXVK are “adaptor” layers (each convert one kind of API interface into a different kind - Wine doing Windows API to Linux API conversion and DXVK doing DirectX API to Vulkan API - and nothing more) whilst Proton is more a controller that just manages those things and adds some more functionality on top such as Steam integration for ease of use.
Without Proton users would have to know a bunch of command lines parameters and environment setup to launch all the right components with the right configuration so that they can first install and then run their Windows game in Linux. In fact this is the situation if you use Wine directly without something like Lutris to do a similar work as Proton.
Personally I prefer Lutris since it’s more flexible - for example I can configure it to run games sandboxed with networking disabled - and it’s not tightly bound to a single games store.
I used to use Lutris, but I found Heroic more consistent and convenient for filling the same purpose. It’s quite good at downloading just the diff needed for GoG game updates these days, for instance, which is key for big games like Baldur’s Gate 3.
I’d say it’s something like a babelfish. You speak English, I hear Spanish.
I think the example you’re using is closer to emulation.
I’m not an expert by any means, most of my technology experience comes from hardware. But Proton isn’t changing the Linux ecosystem, and the programs are still expecting a windows environment when they’re run via Proton.
From what I recall, Linux and windows can both do the same stuff, they just have different names or different ways to ask for resources. And Proton receives the request for whatever and converts it to the Linux equivalent.
It’s not nearly as bad as it was in the past, now that the graphics APIs are system agnostic.
Well, technically speaking, neither would be emulation because both systems are running on x86.
I think it’s what Valve has branded their fork of Wine. It translates win32 calls to Linux ones, and DirectX to Vulkan. Probably some other stuff too idk
Proton is Wine plus DXVK and VKD3D, as well as a big pile of little tweaks and out of tree changes that Valve maintains to specifically maximize game compatibility and performance.
It sounds a lot like what the GPU driver providers used to do (and probably still do, despite all DX12 and Vulkan’s promises of making that unnecessary) on top of making the drivers.
And that is basically “fixing badly written games so they perform well on the hardware”.
As far as I can tell, Intel has been using
Proton’s fixesDXVK to get their drivers working on older games on WindowsDXVK is not “Proton’s fixes”. It exists as a separate entity whose development Valve has helped fund and who Valve devs have directly contributed to.
Proton’s fixes are out-of-tree tweaks to DXVK, Wine and VKD3D that, put together, make games work much more seamlessly and smoothly than they otherwise would.
What part of this did you interpret as a dismissal?
I also wonder how much of it is RADV vs AMDGPU drivers. Wonder what the result would have been if the Deck used the AMDGPU drivers instead. Saying it is just “the magic of Linux” papers over a lot.
I think it doesn’t really matter, in the end the question is, do I get a better experience as a consumer on Linux or Windows?
For every game that you claim runs worse on Proton you can find dozens that run better or at least as well as Windows.
I’m not sure what you’re saying. Proton is incredible obviously, but by itself it doesn’t make games run better. Using vulkan instead of DirectX could improve performance, but presumably most of the performance gain is from not running windows in the background.
It’s a bit of both, along with the Linux AMD drivers being superior in many cases to the Windows drivers.