You mean an os not filled with spyware bloat runs faster than one that is filled with spyware bloat? That’s wild
My first thought as well. “To the surprise of no one…”
They tested exactly two games
I mean Tom’s Hardware didn’t test anything, the Youtuber they are writing about tested Hogwarts Legacy and Kingdom Come Deliverance 2
I will assert that there are more than two games on the market
Imagine my utter lack of surprise
I’d love to see the difference it makes to battery life.
I switched my gaming laptop to Linux and the battery life more than doubled (while not gaming)
for the heavy games, itll likely not change much.
however with light loads and low clock gaming (e.g 2d clocks playing like dead cells or something) the cpu governor on linux is far more efficient. Microsoft is pushing that game to game optimization on the handheld makers when it should really be them doing it.
for the heavy games, itll likely not change much.
Unless maybe you cap the fps.
Example from the article, Hogwarts needed 35W to reach 60fps on Windows, and only needed 17W to reach 62fps on Linux.
If you cap the fps to 60, then you also let the system rest when it manages to render a frame more quickly than 16.6 ms, saving more power in calm moments or maybe while menuing/managing inventory/reading quest logs (most games don’t have intense 3d graphics in the menus).
It’s bad test.
Watch the video the tdp, clock speeds for cpu and gpu are much higher on Linux which accounts for the differences
So battery life would be much better in windows since it’s running fast more conservatively
My whole-ass PC got a huge performance increase going from W10 to Arch (SteamOS), and that’s even with using Proton/Wine.
Thats hard
Interesting! Are the games tested on proton as well? Because if so that’s even more impressive.
I don’t think Kingdom Come: Deliverance 2 has a native Linux version, so yes, these results are achieved using Proton.
This is both a remarkable achievement for Valve, CodeWeavers, and everyone involved with the development of these compatibility tools, as well as a pretty damning showcase of Windows’ performance, even when configured as a somewhat debloated special handheld version.
I don’t know Cyber Dopamine’s credentials and don’t care enough to look.
But this has come up a lot in the past. And most of the time the difference between the OSes (assuming you turn off the most blatant of things) is noise that would disappear if your sample size was large enough and is comparable to the kinds of variations you see when all software is fixed but you have two different CPUs of the same model from the same batch but with slight manufacturing variance. Gamers Nexus and Level1Tech have both discussed this to varying degrees when going over their testing methodologies.
But if you are just doing the first run or two? THAT is where the very noticeable differences come in. Because shader precaching is a thing. At a super high level, it is the idea that every computer is unique and there are tweakable “knobs” that can improve performance when rendering things. Shader Precaching generally refers to testing and setting those knobs ahead of time to maximize performance. That is a VERY incorrect summary but it gets the point across.
Some games have an obnoxious 1-10 minute wait the first time you boot it up because they are, in the background, running through all of that to build that precache. Others say “fuck it, we’ll do it live” and you have a performance hit the first time you load an area or asset… that can be REALLY substantial on that first boot when EVERYTHING is being loaded for the first time.
But, because Linux tends to run games through (time to piss more people off) an emulator like Wine/Proton, it is already generally doing a translation layer even before the shader math. So that is why Steam will often push “good enough” defaults to linux clients every day and there is a setting to even optimize those for your system in the background while you whack it to your favorite onlyfans account.
But… that also gives Linux a pretty big advantage on that first boot on games that are doing it live. Because… we aren’t doing it live.
It might have been phoronix that actually did a deep dive on this? But the various blogsites love to either run their own numbers or find a youtuber who did, not take this into account, and get those juicy clicks.
because Linux tends to run games through (time to piss more people off) an emulator like Wine/Proton
It’s not that this will piss people off, it’s that it’s factually inaccurate. Wine Is Not (an) Emulator. It’s right there in the name. It’s a compatibility layer. You aren’t emulating Windows.
(But this nitpicking doesn’t have any impact on your point overall regarding shader pre-caching.)
While I agree that more extensive tests would be interesting, there are quite a few inaccuracies in your argument that make me disagree with your conclusion.
Firstly, Steam’s shader pre-caching does not work like that. There are no “good enough” defaults being generated every day. The caches you may receive have been generated and uploaded by other players with the same compatible system configuration (I think GPU and driver version, but there might be other factors I’m not aware of). So you only receive shader caches when someone else with a compatible system has uploaded them already. Furthermore, these caches aren’t necessarily complete. As games often compile shaders on the fly and not everyone plays every bit of content in every game, local compilation still happens pretty regularly.
Secondly, shader compilation is by no means limited to the first launch of the game. When the game itself doesn’t have a dedicated (and comprehensive) shader compilation step at startup, shaders may have to be compiled every time you access content in a game that you haven’t seen before. Sure, this is most noticeable at the start of the game, but it might also happen when the final boss enters its sparkly third phase, punching your stuttering, shader-compiling butt into the next wall (which might also require further shader compilation).
Lastly, I disagree with the general assessment that these advantages are somehow invalid because they might be limited to shader compilation stutters. When I download a new game, I want it to run properly. The shared precompiled shaders are a great solution for a bunch of stuttering, and they are only available on Linux because they actually require the compatibility layers. Microsoft hasn’t implemented something similar for their new shiny handheld. So I think it’s absolutely legitimate to call them out on their unoptimized device. I think, for the end user, it’s really just semantics to discuss whether the issue at its core exists because of Linux or because of Windows or because of caching or because of some unknown deity who just really likes Gaben. The fact is: from the data we have so far, it looks like Bazzite is a better experience on a handheld Microsoft co-developed when compared to Windows. And that’s both very sad (because I’d really like to have some serious Steam Deck competition) and really funny (because seeing a very big corporation’s gaming division fumble everything they do makes me giggle).
… Also, Wine is not an emulator, but I think you know that. ;)
not everyone plays every bit of content in every game, local compilation still happens pretty regularly.
Yes. Which is why I emphasized that this mostly comes into play on the first boot of a game and would go away VERY rapidly if you ran multiple collections.
It is not limited to the first launch but it is most noticeable on it.
The shared precompiled shaders are a great solution for a bunch of stuttering, and they are only available on Linux because they actually require the compatibility layers.
Funny enough, MS have been talking about (and implementing?) that for their xbox store games or whatever. Which is actually a REALLY good approach if you ask me.
The fact is: from the data we have so far, it looks like Bazzite is a better experience on a handheld Microsoft co-developed when compared to Windows.
No, we don’t. Which is my point.
Again, I would love to see a rigorous methodology that argues this (and if I am not familiar with Cyber Dopamine’s game, please, someone link me to their methodology). But I have a scientific background: I can cherry pick whatever you pay me to cherry pick.
And, quite honestly? If the performance is mostly noise outside of that first boot after a major patch? That might be awesome if I am paying 80 bucks to play a 4 hour CoD campaign once. That is less than meaningless if I am looking at something like Crusader Kings 3 where I will log hundreds of hours before the next one.
Which gets back to… what is the point of looking at benchmarks? Is it to feel happy that your team won? Okay. You do you. Or is it to make informed decisions.
And as someone who would really prefer Linux (Proton or otherwise) to be a first class citizen? Actively misleading people is just going to hurt in even the medium run.
… Also, Wine is not an emulator, but I think you know that. ;)
My inner pedant thinks that it is worth actually looking at the definition of an emulator rather than the title of software. But mostly it is just a good way to weed out the people who were never going to engage in a good faith discussion :)
the wine part, its more or less based on the end goal of the software. traditional game emulation is software that is used to try to mimic the hardware in question. Wine focuses on trying to be windows, rather than the physical PC hardware itself, so the type of thing youre trying to emulate is fundamentally different.
emulation in general is functionally a compatibility layer. Wine exists on the highest level of compatibility layer because its not trying to rewrite what the hardware is necessary doing (as both the hardware is the same)
Wine is the same level as Teknoparrot is (teknoparrot is compatibility layer for arcade maches that use X86 based pcs for hardware), vs MAME, which emulates non x86 based arcade machines.
it gets mega pendantic because of how closely emulation and compatibility layers are intertwined, but they arent two overlapping circles. a compatibility can use emulation but doesn’t require it.
I just like defining the difference between the two simply by the goal. emulation targets machine to then get to software, where compatibility layers target the software directly. and will target hardware only when necessary.
Those quicker sleep and resume times speak for themselves though
But they also have nothing to do with moment to moment performance. And I would argue that people, generally, aren’t pulling out a steam deck or a 1000 USD xbox to play a quick hand of Balatro while in line at the bank. I love that waking up my bazzite box under my TV actually takes less time than the nvidia shield I watch youtube on. I am not going to pretend that there is a meaningful difference between a 20 second boot and a 2 minute boot if I am sitting down to get angry at Silksong again. Same with my Steam Deck where I usually push the power button and then put the case back in my bag on a plane or off to the side while I get cozy at home.
Its similar to the initial OS install. I will never stop being enraged when I have to deal with cortana and all that bullshit to install windows on a box. I positively love that most Linux distros are like 3 clicks and then a two minute wait if I am not doing weird partition shenanigans. But that is more a plus to the OS and not a reason I would upend my digital existence.
Whereas this article is very specifically about moment to moment framerate.
Microsoft discovering why Xbox wasn’t built on Windows on the first place.
That’s incorrect
https://en.wikipedia.org/wiki/Xbox_system_softwareSure, I mean more specifically not just a skin on Windows.
Laura Fryer, one of the Xbox founders, had an excellent video on this https://youtu.be/lFG7YxFFCnY
Literally every Xbox so far had used Windows for the os, albeit with a ton of modifications, cutting out features it doesnt need
