Slashdot Mirror
The Completely Fair Scheduler's Impact On Games
eldavojohn writes "We've heard a bit about the completely fair scheduler previously, but now Kernel Trap looks at the implications this new scheduler has for 3D games in Linux. Linus Torvalds noted, 'I don't think any scheduler is perfect, and almost all of the time, the RightAnswer(tm) ends up being not one or the other, but somewhere in between. But at the same time, no technical decision is ever written in stone. It's all a balancing act. I've replaced the scheduler before, I'm 100% sure we'll replace it again. Schedulers are actually not at all that important in the end: they are a very very small detail in the kernel.' The posts that follow the brief article, reveal that Linus seems quite confident that he made the right choice in his decision to merge CFS with the Linux kernel. One thing's for certain, gaming on Linux can't suffer any more setbacks or it may be many years before we see FOSS games rival the commercial world."
I have Windows XP and Gentoo Linux running side by side, and strangely, Gentoo scores 10 to 12 FPS faster in World of Warcraft, Warcraft III and even Doom 3. Granted they are commercial games, but if they can run in WINE that fast, I wonder what a direct Linux implementation would do. I just love seeing folks buying the headlines instead of blazing their own paths.
That's why the world is in the shape its in... the majority is always waiting for someone to save the day. You want desktop Linux? Then make it your desktop. Otherwise stop bitching and post some valid comments.
" What luck for rulers that men do not think" - Adolf Hitler
Schedulers are actually not at all that important in the end: they are a very very small detail in the kernel - Torvalds
Actually, I'd like to see the OS kernel consist entirely of only the scheduler and the thinnest APIs to secure drivers granting access to the HW. Everything else, including IPC, could be in userspace.
That would make distributing the OS a lot easier. And the simplicity could be a lot easier to secure, to develop for, to customize a deployment for minimum HW (like eg. a "self-winding" 10mW Bluetooth ring with "accessory" features). Practically every device could run the same "OS", with modules bolted on for increased functionality on heavier HW.
--
make install -not war
Con's SD scheduler is light years ahead in terms of desktop computing and gaming. The "Completely Fair" Scheduler is not. Linus made a poor political decision that once again favors the multi-CPU, gobs of memory, server architecture that normal people don't give two shits about.
Of course they're in the minority. For them, there's nothing to be gained in providing their services for free.
The publicity for working on games is almost nonexistent. For example, can you, name any artist that worked on any one of the most popular games? I can, but I know a bunch of artists that work in the games industry.
Besides, artwork doesn't work as FOSS. Unlike code, artwork for games isn't inherently "sharable" - it's designed for the purposes of that game and that game only. Game engines can be used for multiple different kinds of game. Artwork almost always can't. It may be used for sequels (but generally isn't as the requirements change from game to game) but it can't be used across different types of games.
You are on to something here. CK uses arrays and has a lower context switch time whereas CFS uses red-black trees. What this means is that doing a bunch of "while :; do done" loops that always use their full timeslice is a test that favors CFS as much as possible really.
As an aside, what kind of retard benchmarks a scheduler using a game that is doing nothing and 100% cpu tasks? Put some disk access in there, maybe a set of folders that will easily fit in cache and then find . them. Have some fixed-seed random busy / sleeps of different ratios. Have the game play a demo reel on repeat and record avg *and* min/max fps. Come on Ingo must be somewhat familiar with CK so he must know that these tests where CK is roughly the same are biased toward CFS to begin with. If you are going to say 'look I did these benchmarks and it's a wash' and use that as a justification then at least do good benchmarks.
I think this more than anything else confirms my impression than Ingo is just hacking shit until it kinda works ok. Note that this is exactly the same kind of rationale Linus gave for diss'ing Con so flame off.
Besides, the biggest barrier to 3d games in Linux is video card drivers (ATI, I'm looking at you!) as 3D drivers in Linux, even the proprietary ones, have tended to be unstable.
I would think that the biggest barrier to 3d games in Linux would be the inherent paradox concerning the lack of 3d games.
No gamers = No profit for game companies = No games being produced.
No games = No gamers = No profit for game companies.
The one thing that I would agree on is that video card support brings game developers and gamers closer to a certain extent. Having better drivers might get both gamers and developers to consider Linux a *little* more. However, even if Linux had terrific video card drivers that were just as good or better than the Windows drivers I still wouldn't consider Linux for games just because there's very few good games available.
Better drivers can only help. But I can't consider that the "biggest" problem. The biggest problem is that there are too few people who use Linux. So video card manufacturers don't care about Linux. Game developers don't care about Linux and lastly (most) gamers don't care about Linux.
I realize there was a lot of bad management decisions involved, but look at what happened to the last company that tried to make a business out of porting titles to Linux (*cough* Loki *cough). I have just about every Loki title that was developed and I really wish they had stayed afloat. Maybe it was bad business decisions and maybe it was just that there was no profit in porting titles to Linux. The situation might be different today and I hope that someone has the desire, balls and money to step up and try what Loki tried 7 or 8 years ago. But Loki's fate did send a clear message. There's no profit in Linux games. John Carmack also said back then that releasing Q3A for Linux saw no profit.
Hopefully as more desktop companies, like Dell, jump on board and push Linux then maybe both the game developers and video card manufacturers will start to see the potential for profit and a result gamers will jump on board. But even Mac has suffered from the same problem for 20 years, and there's way more profit in developing for Mac than Linux. And it shows. There are more commercial Mac games than there are Linux. But both Linux and Mac have next to no games at all when you compare to the titles available for Windows.
I keep wondering...X is a single threaded server, communicating with a (generally) single threaded game. Worse, wine inserts the wineserver process, so I have three single threaded things trying to synchronize to get interactivity. A low latency event like a keypress might require all three processes to be scheduled in succession, to get a response on the screen. A poor man's way to do this is with the kernel's scheduler, but a far superior way to do it is to have multiple threads in the X server. Scheduling an interactive event isn't hard. Getting crap on the screen in the same scheduling timeslice is hard (impossible?) since it requires a second scheduling point. As I understand, this is how BeOS achieved substantial interactivity in the presence of load -- my having a multi-threaded graphics server *and* kernel.
So, how much can be gained by rewriting X, or going to a different graphics server? Or do I completely misunderstand the effect of X?
-- Bob
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
Usability research has shown, that variation in waiting time is actually a bigger irritation for users than waiting time itself.
I have seen several projects, where user interface response time problems have been "improved" by making adding a minimum response time. The average response time increases, but variation decreases, and the user often reports the program as having become faster... the logic to this seems to be, that the user wants the user interface to have a predictable response.
I think the reference for this is Søren Lauesens books about usability programming, but I cannot remember for sure right now.
Not only is it possible, but it's widely used in many RTOS. For example QNX lets you select scheduling algorithms on a per-thread basis: http://www.qnx.com/developers/docs/6.3.0SP3/neutri no/prog/overview.html#SCHEDS
Ever heard of MMORPG's? What's to stop one of them being driven by FOSS. Still a service model and can make money as a result.
Well then, everyone, let's head over to Project Peach: http://peach.blender.org/
Yes, the blenderheads are at it again, and they are doing a game this time...
[--- PGP key and more on http://www.root42.de ---]
I think that could be emulated by the window manager renicing programs on the fly.