Live data from Hacker News

Linux gaming is faster because Windows APIs are becoming Linux kernel features

xda-developers.com

231–240 of 694 posts

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#231
post #26

Earlier quoted context omitted.

Their gaming marketshare is minuscule both on PCs and consoles already. It's a downward spiral for years already.

wow that's interesting. Where is the gaming share moving, if not pc and consoles? I guess hand-held devices (do those not count as consoles?) and phones?

They're talking about Microsoft's gaming marketshare.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#232

Show me the numbers. Show me an identical gaming PC running Windows 11 and then Linux, and show not just FPS - but things like frametime pacing, latency, etc. This NTSync stuff is very impressive, but I haven't seen a lot of end-to-end numbers versus Windows. The last comparisons I saw showed pretty much every distribution on the order of 5-30% behind Windows, varying on the game. And Nvidia GPU support was still not…

Unless you're playing CS competitively and really need 720fps for your 360Hz monitor, is 5-30% fewer frames (all else equal) really a deal breaker? Is this hardware thats barly good enough or something else? I ask because I feel like I can frequently play games at, say, 150fps, and losing 30% would mean almost nothing to me to switch to Linux. I worry more about general capatibility and anticheat.

100 fps to 95-70fps is definitely noticeable, 30% is way too much.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#233

Show me the numbers. Show me an identical gaming PC running Windows 11 and then Linux, and show not just FPS - but things like frametime pacing, latency, etc. This NTSync stuff is very impressive, but I haven't seen a lot of end-to-end numbers versus Windows. The last comparisons I saw showed pretty much every distribution on the order of 5-30% behind Windows, varying on the game. And Nvidia GPU support was still not…

I think the actual answer you are looking for is this paragraph: > These old workarounds got subtle edge cases wrong in ways that produced occasional hitches, deadlocks, or weird behavior in specific games, which are bugs that don't show up on benchmark charts but can absolutely ruin individual experiences. NTSYNC fixes those at the source by matching Windows behavior exactly, and that means as soon as your favorite…

> NTSYNC isn't faster, it's more "correct".

It depends on what you're using now, though. If you're just using a vanilla wine/proton install, then NTSYNC should indeed be a lot faster as well. If you're using fsync or... I forget the name of the other one... then you many not see much in the way of perf improvements.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#234

Show me the numbers. Show me an identical gaming PC running Windows 11 and then Linux, and show not just FPS - but things like frametime pacing, latency, etc. This NTSync stuff is very impressive, but I haven't seen a lot of end-to-end numbers versus Windows. The last comparisons I saw showed pretty much every distribution on the order of 5-30% behind Windows, varying on the game. And Nvidia GPU support was still not…

Your initial baseline was arbitrary. If the game had been 10% slower on Windows, would you have never enjoyed it? If not, how could switching with a 10% penalty be a deal-breaking downside?

Just do it. Swap and let go of objectivity. Let your subjective experience guide you.

For me, the subjective joy of not having to fuck around with Microsoft's bullshit was worth multiples of having to mess around with technical crap to get a game working (spoiler: I nearly never have to do that because I play single player games, Dota and CS). I couldn't give less of a damn if my FPS in some random title is 10% slower than it would be in Windows. So long as it's playable, I benefit in spades from the trade-off.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#235
post #6

“ He who fights with Windows should see to it that he himself does not become Windows. And when you gaze long into ntoskrnl, ntoskrnl also gazes into you. ” Seriously, is it really a victory if you have to adopt the architecture of your sworn enemy?

Microsoft and Windows were never the enemy. To quote Linus Torvalds from 1997: "I don't try to be a threat to Microsoft, mainly because I don't really see MS as competition. Especially not Windows - the goals of Linux and Windows are simply so different."

Personally I used to be a Linux zealot back in the early 2000s, then I actually learned to program C++ and dove a bit into OS architecture... I realized why Linux on the desktop always sucked.. Not because of some dastardly conspiracy by Microsoft, but because of the very basic fact that server people and vendors held the developer purse strings and they drove the engineering decisions.

Let's take a simple example.. to send a network packet to a different machine, you just call into the Linux kernel, which dispatches your stuff directly to the network card, and you're done. Pretty simple. However if you want to send a message to your neighboring X11 window, you have to go into the kernel to do IPC, which then somehow dispatches your message to the server process, unblocks and schedules the message pump in X11, which finds your window, then once again you go back into the kernel... then your target process is scheduled, so on and so forth.

Wildly inefficient, yet Linux never got proper good IPC merged (until binder), low latency audio sucked, and none of this coordination logic or audio processing got in the kernel.

Why? Because servers don't need that stuff and some server engineer isn't going to know or care about your use case, you're just small fry, and none of the stuff you do is worth taking on technical risk or slowing down server workloads.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#236

Earlier quoted context omitted.

Although, eventually NVIDIA will drop support for your card and you’ll have an annoying situation. This happened for Pascal on Arch Linux a while ago. The 10X0 series are pretty old at this point, but then Linux shines on older systems too.

You can still use the old drivers they work fine. This also isn't unique to Linux, Nvidia's latest Windows drivers also don't support 10 series cards anymore.

Unless the old drivers have security issues, then you're stuck with the nouveau driver which sometimes only has very basic support for some GPUs.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#237

It's actually been a couple of years since I ran across a game that didn't work well on Linux. At most, I have had to bump the default Proton version.

It really depends on the type of game you play. As everyone points out, kernel level anti-cheat is a problem on Linux, but also games that require odd controllers have trouble as well. One game I play, Farming Simulator 22, doesn't work well on Linux because they use the raw windows input from joysticks and wheels. You can still play with mouse and keyboard, but the fun isn't there.

I was pleasantly surprised at just how many of my games worked well on my new Ubuntu install. Even more so at how many games are playable on my Xubuntu Chromebook install.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#238
Personally I don't know if this is some weird compatibility stuff for Windows apps, or the reason why Windows apps on Linux, whether running via Wine or being ports, rely on these apis because no good alternatives exist.. And if these apis are going to be used/useful for stuff beyond Windows compatibility, for native Linux apps.

Which is a weird thing to think about, and not sure very lovely.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#239

Earlier quoted context omitted.

For one, DisplayPort doesn’t support HDR output

The cable length limitations are also a pain in the ass for not-uncommon A/V system configurations. 6' recommended max, and the best you might get working stably if the device and cable gods smile on you is 15'. 6' is the lower edge of acceptable for just about any A/V system setup (in practice it means your devices need to be within about a meter of the screen's port[s], which is pretty close) and even 15' is still…

For 4k at 60Hz, you'd need HDMI 2.0 or DP 1.2. At those speeds, both kinds of cable should be able to reach 25 feet, and I can find reputable brands selling both kinds at the length.
Post reply on HN