Live data from Hacker News

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

xda-developers.com

391–400 of 694 posts

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

#391

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…

If memory serves, Linux typically outperforms Windows with AMD and Intel graphics. Some of the gotchas are things like running games through Proton or anti-cheat/DRM stuff not getting the same attention that Windows does, but the raw performance is there. I wouldn't recommend using Nvidia on Linux though.

> I wouldn't recommend using Nvidia on Linux though.

This was true 4 years ago, but is outdated knowledge now. Nvidia used to disallow distributing drivers with distro images, but they have since made agreements with some popular distros. If the distro image you download includes drivers or you know how to install them, the proprietary drivers work really well.

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

#392
post #318

Earlier quoted context omitted.

I don't think that's necessarily true, I think companies are lazy and highly invasive anticheat is an easy win they can license from a 3rd party. Algorithmic security, server-side heuristics, and human review can get you far. I have very, very rarely seen a blatant cheater in Overwatch (maybe 3 times in 10 years?), for example, and yet it's been playable via WINE for almost its entire lifetime.

I recently had my faith shattered with I saw someone lock onto an ally through a wall in a kill cam, and I haven't played sense. Blatant cheaters are bad in some ways, but subtle cheat are far worse imo.

There's no reason that kind of client behavior can't be detected server side.

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

#393

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.

Same. I admittedly don't play a lot of new games, and I don't do online games, but like 95% things Just Work when I load a Steam game on my box. The remaining five percent are fixed if I change the Proton version to GE Proton.

I played through Miles Morales at full specs a few weeks ago, and it ran just about perfectly as far as I could tell.

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

#395
post #70

Earlier quoted context omitted.

I was faintly surprised that my recent monitor purchase came with a displayport cable. Didn't help connecting it to my Macbook, but still..

Don't most monitors ship with DisplayPort cables? All of mine have. HDMI is more popular with TVs/home theater systems.

Outside of the ones built into laptops, all my "monitors" for the last decade have been TVs, just because they tend to be cheaper at a "price to size" level.

None of them ever seem to have DisplayPort.

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

#396

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…

[dead]

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

#397

I developed for windows before moving to linux. I was surprised to find that was no system call similar to windows WaitForMultipleObjects. Sure you can implement something similar using poll() or using condition variables. but WaitForMultipleObjects seems so much simpler and more versatile

The article mentions this: "A few years back, Linux added a way for software to wait on several events at once, which is something Windows had built in for decades, but Linux didn't." This is not really my area, but from a quick web search, I think they mean io_uring. Here's a blog post about it: https://mazzo.li/posts/uring-multiplex.html

No, I believe it's futex_waitv

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

#398

Earlier quoted context omitted.

What really drives me nuts is smart TVs with 100mbps Ethernet connections. When I bought a tv we looked in vain for gigabit Ethernet.

With what feels like weekly posts about someone being shocked their smart TV is showing them ads, I'm surprised you looked for gigabit for your TV. I've had a smart TV for over 5 years and never connected it to the Internet.

I connected my Samsung TV to the WiFi for the first time two weeks ago because I wanted to play with the multi-screen-view thing, and it didn't appear to work with two HDMI cables.

It has not shut up asking me to update the fucking thing. Every time I turn the TV on, about twenty seconds later an update prompt will pop up, and it will not go away until I actively dismiss it. This happened even after disconnecting and forgetting the wifi. Never again.

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

#399

Used to be a staff member working on an x86 OS called CTOS. I realized if I implemented a couple of traps, we could run command-line DOS programs. So I did. And it worked. Dev tools, text processing, piped commands all worked. It helped that the DOS executable format was the same as the CTOS format - because we had traded Bill Gates our linker (which produces executables) for his BASIC compiler.

if I implemented a couple of traps What does this mean? System calls?

Need to pee? Take the a-trap to Shell.
Post reply on HN