Hacker News Reader

Comment by marcodiego | Hacker News Reader

No other OS is as configurable, adaptable and versatile as Linux. It runs on the biggest super-computers, on the helicopter that flew on Mars, on the server that is hosting this service and on the device I'm typing just now.

Now, just imagine... just imagine how much performance could be gained if game vendors didn't ignore it.

View on HN

> on the server that is hosting this service

I’m not sure if it changed, but last time I heard HN was running on FreeBSD: https://news.ycombinator.com/item?id=16076041

> just imagine how much performance could be gained if game vendors didn't ignore it

In the case of FreeBSD, Sony used it as the base for the OS on PlayStation since PS3.

> No other OS is as configurable, adaptable and versatile as Linux.

BSD wants a word with you.

From games consoles to core internet devices powering the packets to enable you to post.

Linux may be having an up-trend at the moment but BSD has already been there and still is.

Yes, BSDs are great technically and popular enough to be noticeable.

Unfortunately, most of BSD innovation stays locked behind proprietary forks.

> BSD wants a word with you.

BSD is great for many things, but hardware support is sadly behind. I'm a Linux guy but I run both XigmaNAS as my server and OpnSense as firewall on two different platforms, and all their WiFi and Bluetooth chipsets are unsupported, especially 802.11ac is way behind. Not that I'd use all of them on those machines for security implications, but having them supported could be handy sometimes.

If the complaint is WiFi and co, that's not the fault of BSD.

That's the fault of vendors not opening up their proprietary firmware blobs up to other systems.

So it could be as versatile as Linux if someone would actually make it versatile? Does not sound very versatile at all.

BTW BSD had its last release in 1995, so you probably mean something else.

Saying "complain to vendors" isn't an answer for 99% of users (unless you're a corporate user who vendors will listen to) and basically translates to "it's not worthwhile for you to pick it".

Basically it's the equivalent to a shrug; means you can't do anything with it.

Nobody here is blaming *BSD for not supporting closed hardware: it's a huge effort whose failures are entirely on manufacturers' stubborn refusal to cooperate with anyone that isn't a corporation. Unfortunately that's the reality we must live in today. The point is that Joe User doesn't give a damn about installing closed blobs that can't be examined nor updated, he wants his machine to work, and if it doesn't, he blames the software while switching to something that supports his hardware.

And the RT patches are making it to upstream, which together with the userland sched can make a huge difference in frame rates and latency when gaming.

I doubt they wanna run an RT kernel in SteamOS. There are severe costs to doing so.

I assume the realtime patches brought some improvements you'll get even without compiling a hard realtime kernel. There's a whole bunch of CONFIG_PREEMPT_* options.

Yeah, I've been running my Fedora workstation with preempt=full for years now.

Are there some benchmarks for that, or a good discussion somewhere?

Because I was wondering about that myself. RT kernel sounds at first like it may help achieve better latency in games, but then you are so deep in the stack and depending on overall performance, that the costs of RT mode might hurt much more than one would gain. But I don't really know how that plays out in practice.

I don’t know. My understanding though is that RT Linux adds predicability at the cost of throughput. For games where CPU throughput isn’t important (like an action game where most of the work is pushed off onto the GPU) this would maybe help. Someone could certainly try. But for other games like many strategy games and simulations where the CPU is a limiting factor, there would likely be a cost.

The problem is that it’s not a free win, and games are very varied. But theoretically, on something like a console, you could offer choice.

My understanding is that real-time isn't so much about lower latency (though that is also desirable), but rather about predictable, bounded latency. For the purposes of gaming, no amount of predictability at the kernel level will reduce the amount of work you need to perform to draw a frame, and that is the real limiting factor for most games.

> For the purposes of gaming, no amount of predictability at the kernel level will reduce the amount of work you need to perform to draw a frame, and that is the real limiting factor for most games.

It all depends on what you're trying to optimize for. You can maximize raw framerate numbers by having an unlimited frame queue depth, but it'll feel like shit because you won't have even frame pacing and your input latency will vary wildly. The ideal scenario in gaming is for your draw time to be perfectly deterministic, and be able to schedule things so you can read input and do your render calls just before vsync.

RT is entirely about guarantee regarding response time. It is generally overall slower than non real time in basically any scenario where it doesn’t matter. Video games are purposefully written so as not to be latency critical so RT would be a net loss.

Generally slower at completing long tasks, sure, but is that the real workload of the Deck?

I feel that there's enough aspects and subtleties to consider that I wouldn't trust anyone, particularly not myself, to guess how things are really going to fare. We will likely have a phase of experimentation and tweaking that will improve things with and without RT patches as more workloads are considered and things are ironed out.

I reckon it might be interesting for esports, those types of games where people turn graphics settings way down and purchase very overpowered hardware go push FPS into hundreds, resulting in lower latencies.

Since RT sacrifices throughput for latency you would likely se a drop in FPS, which inturn would also reduce the input processing frequency. sched_ext is much more interesting in that regard as IIRC lavd[1] is for example designed to (ab)use the frequent repetitive access/processing patterns of game engines

[1]: https://github.com/sched-ext/scx/tree/main/scheds/rust/scx_l...

> how much performance could be gained if game vendors

It might not even be the fault of vendors or their developers.

GPU drivers are still a bit of a pain to non technical users outside of PopOS. They need to "just work" transparently to the user or they'll just leave for Windows.

And game devs tend to use a premade engine - that engine needs to have good support for both Windows and Unix, or they will just default to the bigger market: Windows. So that's another important driver in migration to Unix.

I frequently find the best way to game on Unix is to either dual boot or install a Windows VM

I recently tried PopOS because of it's benefits for having GPU drivers configured out of the box and was told that it would "just werk". And to be fair to it, it did mostly just work (ignoring unintuitive UX decisions in the OS generally). But I also spent two days trying to get Steam to show at the correct scale and eventually gave up.

I think that’s just an issue with Steam on Linux, surprisngly. As much as I love Steam sometimes they just leave fundamental things like that unfixed.

The recent 560 drivers for Nvidia also broke the "it just works" nature of Pop!_OS. I run it on my home desktop and managed to dodge that update. As far as I know, those drivers still break some games and have broken DX3D 12 support for Proton games.

This means I have to manage package updates manually instead of just taking the "System Updates" through the UI.

I say all of that, but I'm still far happier to be Windows-free (Linux at home, OS-X for work).

Nvidia Linux drivers have always been a pain in the ass. My previous computer when ever either the driver or the kernel updated would the Nvidia driver would shit itself and boot to a black screen until I switched to single user mode and totally uninstalled and purged any configuration files for them then reinstalled them. I got to where I could type the comands blind on the black screen without single usermode letting me see the terminal I was working in.

They don't ignore it, it powers many servers, and the games on Android and ChromeOS.

Additionally PlayStation OS is based on a FreeBSD fork, and the Switch mikrokernel OS still has a POSIX flavour to it, to the extent that it matters for C and C++ standard libraries.

What they ignore is the desktop mess, and lack of paying customers outside platforms where people are willing to pay even for fart apps.

And now Real-Time support is getting mainlined, which means we might see even more stuff like Mars Rovers running Linux.

What did mainlining it change from the industry point of view? I recall installing in minutes the -rt fork from official Debian repositories ages ago, mainly to have lower/more consistent latency with music apps, and never had a problem.

Official support, and more eyes seeing it. Maybe better integration since they'll need to make it integrate fully to reach mainstream kernel.

Reply on news.ycombinator.com