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."

Comments

1. Cock weapon

[Anonymous Coward]

2. Point at foot
3. Pull Trigger
4. Repeat as necessary

Article is misleading

[RailGunner]

Funny, in the article those framerates for Quake III show CFS beating the pants off of SD.

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.

Linus is right one this one, the scheduler is a small part.

Re:Article is misleading

[Aladrin]

Yeah, I was just gonna post 'Long story short: CFS is better. -yawn-'

Why not just say that, instead of trying to get a bunch of ./ers to RTFA?

Re:Article is misleading

[Anonymous Coward]

So what you're saying is, the headline isn't completely fair?

*bad-dum* *crash!*

Re:Article is misleading

[complexmath]

The performance of the "patched SD" mentioned near the bottom show SD to be slightly better than CFS on the test system. However, a few FPS one way or the another really amounts to testing "noise" -- it doesn't mean anything. If there are any problems with 3D, it obviously isn't common to all systems, which suggests to me that the scheduler isn't the problem. Not unless the problem systems have some background job running that the others don't, which is messing up CFS in some way (and this seems unlikely).

Re:Article is misleading

[Azarael]

Neither the summary nor the FA did a great job of summarizing the issues. I have a vague idea what the schedulers do, but how many readers know what the differences between SD and CFS are? I don't.

It's nice to see the commentary from the mailing list, but without a decent explanation of the situation, the posting isn't informative to many people.

Re:Article is misleading

[Omnifarious]

FPS is a poor measure of the feel of a game. I know it's what all the graphics card benchmarks use, and it does do a good job of measuring the total processor and video card throughput, but that's not the most important thing.

The most important thing is the time between you pressing a key and the changed game state being reflected on your screen and how consistent that delay is.

One of the arguments that CK has made about kernel development is that kernel developers have become obsessed with throughput to the exclusion of all else and that this leads to very poor desktop performance because throughput is a poor measure of 'interactivity'. Someone posting 3D game framerates as evidence of one scheduler being better than another is exhibiting exactly this bias.

IMHO latency is a better measure, but still not perfect and it can be hard to measure in some cases.

I don't know enough about the scheduler to know which one is better or which one exhibits particular properties. But I can see that the throughput bias is evidenced in force in the thread the article points to.

And CK is also right that big iron shops care more about overall throughput than any measure of 'interactivity'. IMHO there ought to be some kind of pluggable scheduler system that allows you to completely change the algorithm to reflect the preferred behavior of the computer you're using.

Re:Article is misleading

[hurfy]

"Why not just say that, instead of trying to get a bunch of ./ers to RTFA?"

I'm gonna guess it worked tho...

hehe, 9 users and 2243 guests online

Re:Article is misleading

[ThosLives]

Neither the summary nor the FA did a great job of summarizing the issues.

I agree to some extent. Notably the test specified in the article is "open a game and then sit there without hitting the keyboard." In my mind, this means the game isn't responding to any I/O, so gets pushed to the background, so adding more tasks just means it gets 1/tasks timeslices. Seems reasonable. I'm not sure why the CFS would keep the game running more often than SD if there was no I/O. An interesting comparison would be to see not only the FPS/CPU usage for the game but also for the "loop" tasks. (Those tasks also are not I/O bound.)

Fundamentally I think the name CFS is a little bit odd - how does one define "fair"? In fact, I probably don't want my scheduler to be fair at all - I want it to run the stuff I want fast, and the other stuff it can run slow. That's not very fair.

So, I would say there is not enough information given in the article to tell exactly why the systems had different FPS performance for different schedulers - just looking at that number doesn't tell how it's splitting the time among all the processes.

Re:Article is misleading

[sumdumass]

I believe that you can swap the scheduler out. I might require you to rebuild the kernel but there is nothing stopping a distro, you or anyone else from using a different scheduler.

And actually, If people think this is a problem, Distro's already heavily customize the kernels so switching this out in their particular kernel shouldn't be much of a problem.

Re:Article is misleading

[ultranova]

Fundamentally I think the name CFS is a little bit odd - how does one define "fair"?

Fair, in this context, means that the scheduler will give all the running tasks CPU time in proportion to their priority (nice level). It follows from this that all the tasks in a given nice level are given equal amount of CPU time, and a higher-priority task (lower nice level) is given more CPU time than a lower-priority one.

SD scheduler (but not CFK, AFAIK) also had idle priority, which means a task that only runs if nothing else at any nice level wants to run. Very useful for running FoldingAtHome.

In fact, I probably don't want my scheduler to be fair at all - I want it to run the stuff I want fast, and the other stuff it can run slow. That's not very fair.

That's what "nice" is for. A fair scheduler respects nice levels, as stated above.

Re:Article is misleading

[harrkev]

In fact, I probably don't want my scheduler to be fair at all - I want it to run the stuff I want fast, and the other stuff it can run slow. That's not very fair.

Isn't that what "nice" is for?
Me too confused.

Re:Article is misleading

[piojo]

I believe that you can swap the scheduler out. I might require you to rebuild the kernel but there is nothing stopping a distro, you or anyone else from using a different scheduler.

I think you're thinking of the IO scheduler, which you can select at compile time. The CPU scheduler is not a choice--you must apply a patch and change the kernel's source for that. And while distros do extensively customize compilation options, the patches that they apply are generally small (besides Gentoo, which is very proud of the patchset it applies to its kernels). For almost any distro, it would be too much work to support multiple kernels (where one is based on unmaintained code).

Re:Article is misleading

[Bob-taro]

FPS is a poor measure of the feel of a game. I know it's what all the graphics card benchmarks use, and it does do a good job of measuring the total processor and video card throughput, but that's not the most important thing. I disagree. Responsiveness is important, but I've never encountered a situation where the frame rate was good and the machine couldn't read my keyboard clicks fast enough.

Re:Article is misleading

[Anonymous Coward]

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.

Re:Article is misleading

[mulvane]

Why not actually write a schedule that has a performance option tunable. Basically, pass a real time instruction to it to optimize how its working so it can switch between SD and CFS on the fly. Seems very possible.

Re:Article is misleading

[garett_spencley]

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.

Re:Article is misleading

[DigiShaman]

What about user selectable scheduler profiles? Would it be possible?

You could switch to one that's optimized for networking (realtime), gaming, server, and desktop.

Re:Article is misleading

[Tacvek]

All schedulers attempt to do that. However the old scheduler design collected statistics based on what process was running at each clock tick. So if a process always yielded right before the clock tick the scheduler would mark it as having used 0 ticks worth of clock time. So it would always stay near the top of the list, and could monopolize the CPU.

A fair scheduler basically times the actual CPU usage. It starts timing when it gives control to the process, and stops timing when the process yields or the scheduler decides to interrupt the process. it tracks processes not by ticks but by actual time used. (This post is based on my understanding of the issue. I may be incorrect.)

Re:Article is misleading

[ArcherB]

So what you're saying is, the headline isn't completely fair?

Or nice for that matter.

Re:Article is misleading

[Spy Hunter]

One of the hardware benchmark sites should invest in one of those high-speed cameras and do some *real* testing of all the latency figures tossed around these days. With one of those cameras you could verify manufacturers' monitor latency numbers *and* benchmark real whole-system latency from mouse click to gun fire.

On an unrelated note, I agree with Linus that a pluggable scheduler is a terrible idea. It is possible for one scheduler to do well on a huge variety of workloads. Pluggable schedulers would just encourage development of schedulers that are 2% better than CFS at one thing and suck for everything else, which in the end benefits very few people because few people do only one thing all the time (and those people can apply kernel patches if they really need that 2%). A desktop workload is really more demanding than any server workload because of the variety of tasks. In many cases desktop users need throughput just as much as server guys do. And kernel developers *do* care about desktop Linux, because as Linus pointed out they use it themselves, and besides, it's a more interesting problem.

Re:Article is misleading

[Hatta]

CK actually wrote a pluggable scheduler framework in an attempt to get his scheduler into the kernel. Seemed like a real cool idea, I don't know any other operating systems that can switch schedulers on the fly. Seems like it was dropped only because of politics. Too bad that.

Re:Article is misleading

[rbanffy]

A nicer solution would be to include more than one scheduler and let the user select it at boot time with a kernel switch. I think that would make everyone happy, even if it required a massive (I doubt) re-writing effort on some key parts. It would make the kernel bigger, but nothing a compile switch couldn't remove.

I am not sure we need a single scheduler for every workload. I am not even sure switching schedulers on the fly is all that hard.

If it is, it doesn't have to be.

Re:Article is misleading

[kisielk]

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

Re:Article is misleading

[abradsn]

Why do you think two schedulers is better than one? I think that better design should meld the two positive aspects into one algorithm, instead of having two different areas to look for and fix bugs, there will be just one. Quality is more important than speed here, because speed will not change much from one scheduler to the next. I think that the main problem that people are seeing stems from that the games themselves are cpu hogs.

Re:Article is misleading

[EvanED]

Isn't that what "nice" is for?

In part, yes, but for some things, it doesn't go all the way.

For instance, Windows will give either the foreground application and/or programs the scheduler things are interactive a priority boost. (I forget exactly what it does.) In theory, this means that the program you're working with at the time gets the attention. It's conceptually like a window manager renicing the processes you're working with when you change focus.

I don't know if it actually makes a difference. It can also cause problems if a program can fool the scheduler into thinking it's interactive, because then it will get a bigger time slice than the priority says it should allow.

There *are* other ways to do scheduling besides just adjusting the nice level.

Re:Article is misleading

[Muzzarelli]

I made the switch from w2k to redhat v8 or 9 about the time that XP came out. At the time I a serious q3 player practising about 5-6 hours a day, playing in leagues, etc. One thing everybody playing did was lower their resolution and raise the refresh rate up to 120 or 125hz, you get smoother view of the game. In both operating systems my machine would easily sustain the 125fps you need in q3, but there were subtle differences in the game.

In w2k at 125hz other players would appear to be moving smoothly. In redhat they would have a constant stutter, like the other players positions were only being updated every 2 or 3 frames, rather than every frame as they appeared to on w2k. This made a difference when playing the game, I ended up moving around distros until I found the preemptive, and low latency patches made the stuttering go away.

For me, fps wasn't ever the problem. It was something else.

Re:Article is misleading

[AvitarX]

Like the Ubuntu Real Time?

Is that patched, or selected at compile?

I always assumed it was patched, and other distros do the same.

Re:Article is misleading

[kiso]

The most important thing is the time between you pressing a key and the changed game state being reflected on your screen and how consistent that delay is.

afaik, physics/ai/movement is always linked to FPS. the better your FPS, the more responsive is the game.

Re:Article is misleading

[TheRaven64]

Why do you think two schedulers is better than one? Because there are competing demands on something like a scheduler. For a server workload, you want throughput, but most of the time latency is not important. The same is true of a lot of HPC workloads. For desktop use, you often want something more latency-focussed. For embedded systems you might have realtime requirements. It is much easier to write three schedulers, each of which does one of these well, than it is to write one that does all three well. That's why Solaris, Xen, and FreeBSD let you select the scheduler at compile or boot time.

Re:Article is misleading

[piojo]

What about user selectable scheduler profiles? Would it be possible?
Linus rejected that because it meant more schedulers to support, and also because he was annoyed that C.K. wrote it mainly to prove that his scheduler was better. It was called "plugsched"--google for it if you want.

Re:Article is misleading

[xenocide2]

Pray tell, what exactly is the point of these alternative benchmarks? The point here is to see how performance degrades under load. Ie, tasks ready to run. The bigger question is, in what way does Igno's OR yours represent real world usage? I can't recall the last time I was playing q3 with seti@home running in the background. From a gamer's standpoint, these benchmarks are bogus. In all cases, the FPS drops with increased load, so the solution is to reduce load as much as possible. That might mean turning off updatedb if you're a late night gamer, etc.

This said, the 3d benchmarking is seemingly not that great, and I've yet to see quality linux benchmarking. Maybe it's time for phoronix to lead the way? I agree that average, min and max fps are important parts. 50 fps vs 60 fps isn't as bad as 55 fps average with occasional 20 fps drops.

Re:Article is misleading

[Svartalf]

But, there IS Output- the GPU is running.

Each frame, you have a wait for engine idle notification. This is an interrupt.
Depending on your implementation of how that is handled, you can be noticeably impacted by the scheduler.

Linus is mostly right- the scheduler is a smallish piece of the whole puzzle. But in the case of a GPU, a stall on the pipeline at the wrong time can and will impact framerates and playability adversely.

Re:Article is misleading

[Anonymous Coward]

What I interpreted from what he was implying, and what you might've missed, is that this new scheduler is, somehow, providing games with more cpu cycles with which they can draw more frames per second and that those cycles have to have have come from somewhere. There's no such thing as a free lunch, etc.

Thus, whenever an interrupt (like your key presses) comes along, whatever process tasked with handling them might get starved because your CPU is busy with the more "important" task of drawing frames - which results in what we traditionally call "lagginess". Now, this probably isn't a problem, because the process handling your keyboard presses is probably the same drawing all those frames, and so it can stop to handle your key presses. In short, everyone gets the info they want, when they want it, and you have all the necessary reaction times for your First Person Twitcher.

What the GP was going at is that no one bothers to measure latency. Whats the point of pulling 300 fps if it takes a second to process your mouse movements?

Re:Article is misleading

[0xABADC0DA]

The point is to create a scheduler that performs well on desktop workloads. That's the point. One desktop workload is playing video games, and as you point out people do *not* play games with several 100% CPU loads going on the background. But there are hundreds of things that happen automatically, such as your clock updating once per second, your web page with news pages that reload every couple minutes, checks for new email, some occasional updates for xfire / pidgin / etc. Things that will typically do a lot of context switches for short durations. My point is that the setup Ingo used was about the worse gaming benchmark one could possible come up with, and conveniently it favored CFS as much as really possible. To me this sounds like somebody purposely trying to defend his scheduler.

And don't get me started on updatedb. Why is it necessary? Because the kernel devs won't put something in that lets usermode see all file changes. Inotify is barely even usable with all sorts of timing issues catching new folders, mounts, etc. Dropped update messages because the watching program didn't read enough events fast enough, very small limits on the number of watch devices and number of inode that can be watched (for example only ~1/2 of the folders on my system can be watched even using all the available watch devices), difficulty correlating inodes into the right place in the fs tree. If you miss anything the watching application has to rebuild its whole view of the watched part of the fs in order to be correct, updatedb style. This kind of problem is begging for a VM like neko as the moral equivalent of a souped up berkeley packet filter but I'll put my money on you NEVER seeing a vm in linus's tree, even one that takes only 200k. At least directly copy the change records directly into the program's space so there's nothing dropped.

Re:Article is misleading

[abradsn]

It may not be easy to do, but I think a single scheduler could accomplish the task at hand. Being serious no one using a desktop of server in the conventional sense has true real time requirements. Real time maybe for embedded systems, and then I can see where a whole tone of different patches would need to be applied to the kernel in that case.

I suppose I could argue about HPC workloads being different from load to load and perhaps differing needs being prevelant in various situations, but I think that I would likely come back to your same conclusion in the end, so I default to your experience here if you have a lot of HPC experience.

I guess that my main point is that Microsoft has an OS that most of the time plays well with servers and with desktops (without needing a recompile). It's not perfect and of course can be improved. I'm just saying that if they are doing it well, they why can't Linux do it at least as well?

Re:Article is misleading

[Anonymous Coward]

I have, though in windows. Counterstike exhibits this phenomenon fairly commonly on maps with many bots loaded though the frame rate keeps moving smoothly.

Re:Article is misleading

[ejito]

If you've ever played an older online FPS before, like Q2, before broadband and clientside fire became standard, firing was delayed by your ping (it took my railgun almost 1 second to fire). That was much better than playing my voodoo2 on half life, where I got 4 FPS intermittently, but where my shots were instant (from the client's perspective). It's much easier to play with a steady FPS than it is to play with unresponsive servers (As someone else has stated, it's not possible to have blazing FPS and an unresponsive client, unless there's some skewed prioritization. You're looking at a fluke if that happens).

Re:Article is misleading

[Anonymous Coward]

The tester still said that CFS was much smoother than SD and that SD was choppy and laggy in all 3 of the 'yield modes' that he tested.

Re:Article is misleading

[Omnifarious]

It's also good if the delay is of a consistent length. You can adapt to a fixed delay if it's small, but it's really hard to adapt to a delay that's jumping all over the place even if on average it's pretty small. Additionally an inconsistent delay length leads to things looking choppy even when the delays are all fairly small.

If you moved a window across a screen and at a particular speed and its position was updated at a fairly consistent once every 2 pixels it would still look pretty darn smooth, but if it sometimes updated every pixel and sometimes every 3 or 4 it would look pretty choppy even if on average it only moved 2 pixels per update.

Having the delay be inconsistent also messes with the feedback between what you see on the screen and how fast you move your mouse.

In short measures like throughput or even just average latency are pretty poor. What you want is a measure of real feedback latency and look at both the average, standard distribution and outliers in various load situations. I suspect what you want a very tight cluster around an average latency and as load goes up you want that average to degrade gracefully while the cluster remains relatively tight.

Re:Article is misleading

[shaggy43]

Solaris can do it: prioctl

Re:Article is misleading

[IllForgetMyNickSoonA]

What exactly are you refering to? I've never had a single stability problem with nVidia drivers, in all the years I've been using them. Granted, I never lived "on the edge", my graphic cards have always been on the low end of the nVidia product portfolio, but nevertheless - their drivers were always a breeze to install (compared to anything else regarding X) and never gave me any serious problems.

Re:Article is misleading

[Anonymous Coward]

Pluggable schedulers would just encourage development of schedulers that are 2% better than CFS at one thing and suck for everything else, which in the end benefits very few people because few people do only one thing all the time

As opposed to... trying to find a generic solution to rather complicated and context dependant problem?

Yeah, sure. Horrible, HORRIBLE idea. Let's just mandate One True Sanctioned mediocre solution that no one is quite content (much less happy) with.

Re:Article is misleading

[DrSkwid]

Average is an almost useless figure.

This may help Programmers Need To Learn Statistics Or I Will Kill Them All.

Re:Article is misleading

[Yvanhoe]

I think that it may take a lot of efforts to make a game run smoothly under Linux (and to distribute it), but that it takes only one or two early and well informed design decision to make it run smoothly inside wine.

Re:Article is misleading

[complete loony]

Also (I believe) if you give up your time slice early, say to block on IO. Your process will be scheduled earlier when that block is released. So while you will get your percentage of CPU time, you should also get reduced latency.

Re:Article is misleading

[Spy Hunter]

I disagree with your assertions. The generic solution is possible and a generic solution is always preferable. CFS is much better than mediocre, and most people will be content (and probably even happy) with it. If you disagree, show me the benchmarks where CFS performs significantly worse than another scheduler, and the difference is larger than the measurement error, and it's not easily fixed within days by Ingo.

Furthermore, CFS is not mandated; people are still free to patch their kernels. Nothing can be mandated in Linux, it's open source! Distros almost always apply many patches to their kernels for issues similar to this.

Re:Article is misleading

[mandolin]

There's no profit in Linux games. John Carmack also said back then that releasing Q3A for Linux saw no profit

You say you have most Loki titles so I assume you will be familiar with this.

Q3A was originally released for Windows in time for Christmas. As I recall, I could not find a copy of Q3A-Linux in a retail store until early March. Partly because Loki really wanted to ship the thing in a tin box that I could not care less about, and perhaps other reasons as well. Meanwhile, Id released Linux executables that would work with their Windows version.

How many fools (besides me) are going to wait around to buy Loki's product to "show their Linux support"?

There may be no profit in Linux games, but as far as I am concerned, Carmack's observation is merely a reflection of the fact that Loki butchered the Q3A-Linux release.

Re:Article is misleading

[joeljkp]

Just a little nitpick, but Loki was not the last company doing commercial Linux ports. The new standard-bearer is Linux Game Publishing, though they've taken a low-and-slow approach and haven't done many big-name games yet.

Re:Article is misleading

[dbIII]

but look at what happened to the last company that tried to make a business out of porting titles to Linux (*cough* Loki *cough)

They were on target - but then the dotcom crash happened and their investors pulled out. Perhaps they might never have made it or perhaps they would have continued to hit targets and become profitable - I don't know.

Re:Article is misleading

[rbanffy]

I will tell you why I think two options are better than one if you tell me why one option that is good for one set of workloads and sucks for another set is better than two that are complementary in their goodness/suckyness. ;-)

Re:Article is misleading

[wellingj]

Once Ingo merges in the rest of the rt patch I think your latency argument will pretty much be a non issue. Then it will be just a matter of the game developers (or wine developers...) using the POSIX interface in an inteligent way (and if they already are no changes will be necessary).
An easy way to check out real time performance is to use the OSADL live CD

Re:Article is misleading

[Anonymous Coward]

FPS is a poor measure of the feel of the game? Typically when you press a button in a game, the longest thing you have to wait for before you see the change is the next frame. Higher frame rate means less time between frames means lower latency. I can't imagine the circumstances under which the rendering code is running at full tilt but the code that's supposed to acknowledge a mouse click and spawn a rocket entity in the game world (for example) is blocking for long periods.

FPS is in fact an excellent measure of a game's responsiveness.
                --Justin

Re:Article is misleading

[Omnifarious]

And isn't prioritization the province of the scheduler? Isn't it supposed to figure it which process really deserves to be running at any given instant based on some heuristics?

I agree that many twitch games will likely have a loop that causes them to check and process user input at least once for every frame. But, what if they don't? Maybe that loop is running in a different thread that pokes a physics engine thread which is updating the game state which is being rendered by a rendering thread? Then a scheduler which made a mistake and created latency in the wrong places could be creating a huge interactivity problem even though the framerate is quite high.

Re:Article is misleading

[bipolarpinguino]

How do you know that Microsoft doesn't use different schedulers in their Desktop editions as opposed to their Server editions?

Re:Article is misleading

[Nevyn]

Why do you think two schedulers is better than one? I think that better design should meld the two positive aspects into one algorithm, instead of having two different areas to look for and fix bugs

Let's take an example that has enough people pushing for it with money, the I/O scheduler. That is completely pluggable, with three or four different versions that are each very useful in different cases ... and the default is still pretty good "in the average case".

As for just make one good one one of the I/O schedulers is "do nothing at all, to save CPU" and then another one is "burn huge amounts of CPU to save seek time". Merging these two scheduler strategies into one would be impossible.

Lest you think that's an isolated incident, consider that with the "recent" TCP_CONGESTION sockopt you can now basically change your TCP scheduler per. network connection.

Re:Article is misleading

[qc_dk]

It is possible to do multiple schedulers. I created a fair-share scheduler, i.e. each user on the machine gets equal slice of the CPU. This i wrote into the kernel and then made it optional. Root could then write a 0 or 1 to a file in /proc/ to turn it on or off. This will ofcourse cost some overhead, so for most people sticking with the scheduler they favour is probably better.

cheers,
Christian

Re:Article is misleading

[Anonymous Coward]

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.

As another post noted, LGP ports games to Linux and have made enough profit to stay afloat for several years now. Funny that Slashdot, known as a place for a lot of Linux fanbois, the accepted truth is that there is no profit in Linux games and that Loki was the last company to try.

Oh, Slashdot did not bother to inform us that the first commercial racing game was just released for Linux by LGP!

Re:Article is misleading

[7-Vodka]

"John Carmack also said back then that releasing Q3A for Linux saw no profit"

Are you out of your phreaking mind? They released the windows version AGES before the linux version. You could also easily buy the windows version, then download the linux binary right from day 1. There was absolutely no incentive to buy the linux version and every incentive for a linux user to buy the windows version and download a small executable to play on linux. All of those sales counted as windows sales, but were actually run on linux. I know because I bought 2 windows copies myself and they both were used on linux machines. I would rather they released information on how many linux binaries were downloaded and made a guesstimate on that rather than using sales number where there was no competition at all by precondition.

Don't forget that almost every dedicated server out there is also run on linux and this was the case from release day.

Re:Article is misleading

[pakar]

With a pluggable scheduler they would open up OPTIONS for people that needs to have a different workload... What's included later into the mainstream kernel is then a completely different thing.. But you could at least have 2 basic schedulers.. One that favors latency and one that favors throughput.. And as previously written here is that latency is much more important in games than throughput.

Or maybe as an alternative to the pluggable-scheduler idea... Just having access to a few of the tunable variables like max-time a process can spend in the cpu (reduce = lower latency, increase = higher throughput), or maybe be able to hardcode how much cpu-time a process can take in one run, or maybe have some switches that enables you to switch to a mode that causes the process to be on the top of the list if it's waiting for some type of input.. Or as from the CK patchset have something that enables you to have a process run ONLY on idle ticks..

The thing here is that there are so many different workloads that it's impossible to have a preconfigured scheduler that suits everyone. And if compared to the windows schedulers as someone did previously here there is a BIG difference.. In windows the scheduler is tied together with the window-manager that enables the scheduler to see what window(s) the users are using and give them a latency/performance boost.

So even if the developers do care about desktop linux i can also say, from my own experience, that coders dont play games as much as other people :)

Re:Article is misleading

[RailGunner]

In my original post I called out ATI. My box with an nVidia card works well, but ATI's linux drivers blow. Hopefully now that they're owned by AMD that will change...

Re:Article is misleading

[junglee_iitk]

Then you haven't played any 3D game which required high interactivity.

I used to play Quake3A on my desktop, the only reason I installed Gentoo back then because my Unichrome driver required compiling X11 sources and all... and this is almost 1 year ago. The FPS was always higher than Linux, constantly fluctuating between 90-120, while on Windows it was constant at 104 (or 105). But while playing, suddenly after some time, the game will halt for a fraction of second. Just a fraction of second! Enough to lose!

That is all this RTFA has. Play the damn game, or ask the users!

Re:Article is misleading

[ultranova]

All schedulers attempt to do that.

Nope. The old scheduler, for example, attempted to give more CPU tasks to "interactive" - as determined by heuristics - tasks more CPU time than other tasks by increasing their priority. Not only did this mean that nice levels would not be respected except as a general guideline, but it also made latency unpredictable, since a task could suddenly and unpredictably get an increase or decrease of priority. This would then lead to stalls in program execution, resulting in skips in audio and video and jerky gameplay.

Con's SD scheduler doesn't have these issues, since it doesn't have dynamic priority; latency, in any given situation, has a deterministic upper limit. I don't know if Ingo's CFS has any heuristics built-in; if it does, it is open to the same problems as the old scheduler.

So basically, the old scheduler was broken by design, and would had always remained broken no matter how it timed CPU usage. Oh well, now, thank's to Con's hard work, we have a deterministic one (or at least more deterministic than the old one) in the mainline. Pity that the -ck patches had to die, thought - I don't trust the kernel people to not reintroduce heuristics back to the scheduler to try to fix broken software.

Re:Article is misleading

[windex82]

Over in the Windows world the ATI drivers aren't much better.

  The drivers that came packaged with two new ATI cards I installed today did not work. They wouldn't install on two PC's running windows XP with the same error about wanting to have the standard VGA driver installed before it would install. For some reason it was unable to detect that the system was using the standard VGA driver. I ended up downloading the latest off the website and they installed without any issues.

Re:Article is misleading

[TheLink]

Just curious: how do you automatically "nice" transient processes?

Say a program forks transient processes off where you'd want different processes to be run at different nice levels?

Would you have to modify the program or other executables?

Re:Article is misleading

[Anonymous Coward]

Now that's something that only a very rare individual would see, which underscores the problem of subjectivity and the need for benchmarks. It's bizarre that there are no desktop responsiveness benchmarks for Linux. The absurd "while :; do :; done" suggestion from Ingo sounds like a joke (I hope it was,) but it doesn't seem impossible to create better benchmarks. Here's one method for managing benchmarks that would work better than the current system:

1. Linux appoints a desktop responsiveness czar.
2. Said czar designates a standard form for publishing benchmark tests. (The standard form would probably be a list of packages to install a script to run, and a script for producing reports from the resulting data.)
3. The czar starts with an empty collection of benchmarks.
4. People develop benchmarks and publish them in the specified form.
5. Benchmarks are tried out and debated by large numbers of people.
6. The czar adopts one or more benchmarks that are not redundant with his current collection of benchmarks.
7. Go to step 4.

Re:Article is misleading

[abradsn]

You misunderstand. I mean the same software running on server hardware and desktop hardware. For example Win2k on a desktop and on a DL 520. Or similar idea with XP.

I also know of a gameshop that develops there game on Win2k and Win2k3 and runs it primarily on XP.

I would guess that mostly they do use the same scheduler though because it would be too difficult to start branching schedulers and the kernel would get more difficult to test. (That's the same thing as perhaps maybe saying that a person may have worked there, and knowing that they try not to make their lives harder if it is possible.)

Re:Article is misleading

[glenroe]

Yes, but perhaps the interesting situation is where frame rate is bad, on a slower machine - that is when the difference between schedulers could make a human noticeable difference in interactive behavior.

FOSS games

[Joe Tie.]

Aren't going to happen until artists in the medium, 'good' artists rather, decide to start working for free the same way coders do. Some artists will work for publicity alone, bu they seem to be by far in the minority. On a technical level, I've not seen much problem with linux. Ogre, for example, runs quite smoothly for me.

Re:FOSS games

[Anonymous Coward]

that's the most ridiculous comment I've heard. enjoy your solitaire knock-offs

Re:FOSS games

[TodMinuit]

I'm no artist -- In fact, I can barely sign my name -- but I do think 3D artists work for free, just not on games. Instead, they tend to focus on high-polygon renders of things, like cars. They want something that is fun and challenging, just like open source programmers. Low-polygon video game characters aren't going to cut it.

Re:FOSS games

[Broken scope]

Maybe I'm wrong but aren't many of the low poly characters in games just simplified from original high poly models. Doesn't normal mapping take that high poly high quality render, the simplify it, then using lighting tricks give it the appearance of the high poly model, while being significantly similar?

Maybe I'm wrong again, but making those high poly models isn't easy either.

Re:FOSS games

[slackmaster2000]

Right. And then artists can make money the FOSS way, with technical support.

Re:FOSS games

[CaffeineAddict2001]

Art is not modular like code. You can mash-up code from 20 different coders and still get something that works well. If you did that with art it would look terrible because you would not have a consistent style.

Re:FOSS games

[OldeTimeGeek]

Aren't going to happen until artists in the medium, 'good' artists rather, decide to start working for free the same way coders do. Some artists will work for publicity alone, bu they seem to be by far in the minority.

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.

Re:FOSS games

[sqlrob]

It depends on the artist.

Are you saying all of "Snow White" was drawn by one person? All 24 fps, 83 minutes worth?

Re:FOSS games

[mwlewis]

No, he's saying that they didn't use any of the "Snow White" art in "Sleeping Beauty" or "Cinderella".

Re:FOSS games

[Anonymous Coward]

Low-poly models are bump-mapped (usually with normal mapping) from the high-poly models. They effectively turn the extra polygons into a texture.

Any schmuck with hobby experience can make a high-poly model. When game development studios hire modelers, they look for people who can do the best work with as few polys as possible.

Re:FOSS games

[Jeff DeMaagd]

Aren't going to happen until artists in the medium, 'good' artists rather, decide to start working for free the same way coders do. Some artists will work for publicity alone, bu they seem to be by far in the minority.

I really don't think that's fair or accurate for either programming or art. A lot of artists give away at least some of their work on the Internet, and a lot of programmers don't do that. Whether it's more prevalent in one field or another, that's a question that can't be definitively answered.

Re:FOSS games

[nuzak]

> Are you saying all of "Snow White" was drawn by one person? All 24 fps, 83 minutes worth?

Bad example. The team of animators on Snow White and the Seven Dwarves was managed to an unprecedented degree, with an obsession for consistency and quality control. This is not the sort of thing you get from hobbyist contributions.

Coders are a dime a dozen, minus the dime. Modelers, sketch artists, musicians, and actors are the fellas you're just not going to easily get on a FOSS project.

Re:FOSS games

[Kjella]

I'm sure they do - in a shape where they create what they want to create.

Creating free for a game means:
a) It needs to be a set, often of considerable size
b) It's usually set by the developers what you need to create
c) You have to create it with the game's restrictions
d) They all need to be consistent in style

In short, it's not free experimentation or creativity. I imagine the average art designer-inspiring-to-be-artist would rather create art than designing up a large set of resonably similar graphics - too much like work. And while I've heard of paid coders, I haven't heard of any paid OSS designers - at best there's a prize in a logo contest.

Re:FOSS games

[Opportunist]

Actually, creating a low polygon count model that looks good is quite a challenge. With today's tools, it's almost getting trivial to make something look good, provided nobody cares if you use billions of polys.

Re:FOSS games

[CuteAlien]

I disagree. Usually a lot more artists work on a game than coders. Also exchanging artists in a project will cause less trouble than exchanging coders. A good artist can adapt his style so it's consistent with the style delivered by others. Integrating additional coders is usually very difficult. And lastly: programming is an art anyway :-)

Re:FOSS games

[Opportunist]

Maybe not, but with the FOSS way of becoming known and hired by companies.

The first thing you get asked when trying to apply for a position as an artist is to show them some of your work. Which is kinda hard if you never participated in any project. And to get a project, they first of all want to see some of your work...

Re:FOSS games

[CaffeineAddict2001]

Snow White could not have been made over the internet for free because you could not maintain stylistic control.

Also, Art has a very specific purpose in mind. It can't be reused easily. Where else are the 7 dwarves going to be used other than Snow White?

Software algorithms can be reused for all sorts of things.

Re:FOSS games

[jessecurry]

I think that with the exception of a few select coders the FOSS developers are mediocre at best, but luckily our computers are more than fast enough to make up for poorly implemented code. Unfortunately, a mediocre artist doesn't have the same latitude that a mediocre coder does. If an artist does a half assed job we will notice it right away, if a coder writes a routine that takes twice as long to execute as it should chances are the end user will never notice.
That's not to say that there are not a lot of great software packages, just that most of them provide a good utility, but are not implemented ideally. Along with artists I've noticed that FOSS overall suffers from a lack of really good UI designers. I think that we'll continue to see a lack of great UI and great Art because there are so few that do a truly great job and they enjoy compensation.

Re:FOSS games

[CuteAlien]

Mostly right. Except for the sharing. Good free textures are still rare and good textures can be used in many games. Also models can to some extend be used in several games. Having for example models of houses in a certain style (like "middle age") would help free games to look good way faster. Same for sound effects - I don't even know any good sites for free sound effects right now.

Re:FOSS games

[sqlrob]

So Linus accepts every patch into the kernel?

Control can be maintained, even in FOSS projects.

Re:FOSS games

[Opportunist]

Of course I can't name the artists. I'm not in the game biz. And I doubt many artists care whether I know them as long as game studios do. The studios will hire them, I won't.

You know a bunch of artists, and I have to assume that you have some ties to the game industry. Now, how many IT security researchers do you know? Probably a few, if that. Doesn't matter though. They don't care if you know them, as long as people who're in the IT sec biz know them, know their name and know their value. You won't hire them.

Re:FOSS games

[Tacvek]

Well it depends on the exact type of artwork. I'll admit that 3d character models often are not usable in other games, but textures can be (especially generic textures).

Re:FOSS games

[gowen]

Predates that. Canaletto was notorious for letting his pupils do the easier parts of his paintings whil he concentrated on the key elements.

Re:FOSS games

[Catil]

Artists usually have a huge archive of unused material, either done in their free time for practice and fun or for games that never used it due to a redesign or cancelation. Even some of the dummy objects most artists produce, to give the coders something to work with, can be better than actual graphics made by a hobbyist.
I always wondered why they just wouldn't contribute at least some early works to the open source community? Is it maybe just the lack of a good website where stuff like this could be indexed or isn't there a good enough standard license model to release something like that for free? I thought the Creatice Commons license would be quite suitabel for it.

Everybody who spent some time finding a good textured and rigged low-poly character model, preferably with basic animations, on the net for use in an open source game, knows that there is next to nothing available. Well, at least not when I could have needed one about two years ago.
It really doesn't have to be that professional or finished - even that untextured rat someone made a decade ago to have something to shoot at, later to replaced by some creatures, could maybe be of use to someone; and if he textures it, and maybe do a simple animation and perhaps record some sounds, and then uses it in his project, he should give the additional stuff he made to other developers as well.
Soon there will be a nice looking 3D rat with some textures to choose from, various sounds, walking and death animations, etc. and everybody did his part. That's the open source way - why does it seem it's not very common among artits and only coders?

Anyway, I think it could be really just the right website that is missing - some Sourceforge-style page with a nice upload-frontend, where stuff gets properly indexed based on categories, tags and styles and with a feedback option, where contributers can see which projects are using their works. Add some voting to rank it, karma, apply a fair license to it upon upload and I think something like this could really take off.

Re:FOSS games

[psxman]

Unlike code, artwork for games isn't inherently "sharable" - it's designed for the purposes of that game and that game only. That's not entirely true - for instance, the portraits from Wesnoth work fairly well for Wikipedia. (the page on Liches uses one, and I could see a lot of other fantasy races using portraits from Wesnoth)

Re:FOSS games

[nuzak]

Yes, and the total output of well-managed asset development in FOSS games approaches zero. Feel free to pull another analogy out, but it won't change the reality.

Re:FOSS games

[Anonymous Coward]

D'oh! Messed up my tags, that'll teach me to preview. My post begins at the second sentence.

Re:FOSS games

[tkinnun0]

Also, Art has a very specific purpose in mind. It can't be reused easily. Where else are the 7 dwarves going to be used other than Snow White?
Slap some beards on them and change the color of their clothes to green and you've got yourself a leprechaun movie.

Art isn't reused because it can't be, it isn't reused because doing so cheapens its value in the viewer's eyes.

Re:FOSS games

[LWATCDR]

Nethack is good enough for me!
I don't think you will ever see a lot of high end FOSS games. How would the developers get paid. Yes I said it get paid. A good commercial quality game is a lot of work. Unless Novell or Redhat decide that they need some games to push Linux where will the funding come from?
What we need are... Closed source games that run on Linux.
There are a few already but there needs to be more and people need to be willing to pay for them.
So if you want FOSS games prove me wrong and write one that rivals the commercial products out there.
If not be happy with Nethack and BZFlag... Which are both really fun games.

Re:FOSS games

[Ford Prefect]

Aren't going to happen until artists in the medium, 'good' artists rather, decide to start working for free the same way coders do. Some artists will work for publicity alone, bu they seem to be by far in the minority.

Erm... Have you seen the world of game mods? Vast numbers of artists (and programmers), ranging from mediocre to utterly fantastic, working for free - often for fun, often for publicity (making a successful mod is a great way of 'breaking into' the games industry), almost all outside the world of open source games.

I made a simple, single-player mod for Half-Life 2 - called MINERVA, it's been downloaded something like 400,000 times or something ridiculous like that. I've paid a bit of attention to first-person open source games, but beyond a couple of interesting exceptions like Sauerbraten, I haven't seen anything that makes me think "ooh, I'd really like to make a map for that." (Sauerbraten's of interest because it's a fundamentally different way of building maps, and could be a fun artistic challenge - the game is the editor, but admittedly the actual gameplay is rather generic.)

Maybe on a technical level, things work fine with Linux - but far too much open source stuff seems to rely on building a very basic, generic framework and simply assuming that other people will come and turn it into a full game. Sorry, but the technical approach isn't necessarily going to work - think of a brilliant gameplay idea, and then work on the technical aspects necessary to make that playable. And please, please stop cloning existing games - if you're programming a game from scratch, do something new - something which will attract free artists and gameplay implementers like myself!

Re:FOSS games

[G Morgan]

Yes the FOSS coders are mediocre. It's just those in the proprietary sector are crap. FOSS code generally outperforms that in the proprietary sector.

Re:FOSS games

[G Morgan]

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.

Re:FOSS games

[DarenN]

Along with artists I've noticed that FOSS overall suffers from a lack of really good UI designers. I think that we'll continue to see a lack of great UI and great Art because there are so few that do a truly great job and they enjoy compensation. There are no really good UI designers working on desktops. If there were, there wouldn't be mixed metaphors and the whole thing would be a lot more intuitive. The colours wouldn't blind you and curves would be easy.
Engineers (both electrical and software) made all the stuff we base our designs on today, by which I mean the UI metaphors we're used to and the frameworks we build on. And they may have been artists but they didn't understand interaction. It's not really something you can learn, either.

Bit harsh on FOSS developers, too. It's a truism that there are more mediocre developers than good ones and that resources are wasted, but that's EVERYWHERE, not just FOSS.

Re:FOSS games

[Anonymous Coward]

So you mean we have to get back to the days of shareware and Future Crew?

Werd, I'm down.

Re:FOSS games

[Anonymous Coward]

Not really, at least for music. A hell of a lot of music today is created by sampling and combining from other peoples tunes. Some of it's literally called 'mash up'.

Inconsistency can create dramatic tension ie, heavy hip hop beats+opera singer, sweet violins over nasty electronica etc.

There may be hundreds of contributors to a track if you include the people who programmed the patches on your synth, those who wrote the software, those who played on the records you are sampling, the guy who hit the snare drum to make the sample for your drum machine.........

Re:FOSS games

[YourMotherCalled]

Maybe not those movies specifically but they have for others!

Disney reuses its "code"

Re:FOSS games

[Bill_the_Engineer]

Have you ever seen Scooby Doo, Josie and the Pussycats, and Speed Buggy?

Re:FOSS games

[CaffeineAddict2001]

Music is way different. Writing music is actually very similar to coding.

Re:FOSS games

[LocoMan]

Well, you can always try http://www.turbosquid.com/ Most models there are for sale, but there are quite a few free ones there. I do remember getting a free model of a football (soccer) ball from there sometime ago.

Re:FOSS games

[Catil]

Nice, for some reason I thought they weren't around anymore. Im remember trying out their client application like 5 years ago. The "forgot password" option even still remembers me ;-)
The selection of free stuff offered there looks very usable, so I will look into the license(s) soon. I see they took up discreet's gmax too, so that's where it went.

Even more interesting is that there is a link on the site to another project, perhaps of the company behind Turbosquid, http://www.gameflood.com/ which looks almost exactly like the site I was thinking of and maybe even goes a step further.
From the description:

Introducing GameFlood, the premier destination for artists, modders, mapmakers, and gamers to create, customize, and play third-party game content. With our powerful, free project and team management tools, you can get your ideas out of your head and into gamers' hands more quickly and easily than ever before.

Using our Mashup functionality, you can create individual weapons or characters, which end users can then mix-and-match into their own creations. Or join one of our project teams, using your existing skill set to help create compelling new gameplay experiences. Oh well, why do I always come across interesting stuff when I have no time, it's like a curse...
Anyway, thank you very much for the link. I really hope I can participate there soon.

Re:FOSS games

[sqlrob]

Currently, yes. But it's possible despite exhortations to the contrary. It's just going to take someone willing to do it.

Re:FOSS games

[Anonymous Coward]

"Where else are the 7 dwarves going to be used other than Snow White?"

Ever notice that there wasn't a bukkake scene?

Re:FOSS games

[Anonymous Coward]

even earlier, didn't da vinci do the same?

Re:FOSS games

[APLowman]

What about Stepmania

Re:FOSS games

[try_anything]

It's not really something you can learn, either.

Well, you can't learn it by shoving one version after another out the door, sitting in front of a computer and waiting for "feedback." You can't learn it by reasoning and arguing and honing your theories to a razor-sharp edge, and you can't learn it by reading other theories written by other people.

You can, however, learn a hell of a lot by sitting behind a half-dozen users and watching them use your app with no assistance. It's just that very few people get to work that way.

Re:FOSS games

[try_anything]

Do you think they all depend on proprietary libraries and run on Microsoft servers?

Unless you mean they could release the actual source code for the game, but I think there's a good reason for keeping the code secret. My impression is that commercial MMORPGs get a lot of unpaid admin work from people who enjoy the prestige, enjoy the power, and enjoy being useful. A commercial company that open-sourced its engine would surely have to compete with entirely free alternatives staffed by volunteers. The only way around it would be to make sure the computing load is non-distributable, so that it required extremely powerful servers to run.

Re:FOSS games

[G Morgan]

Content is more important than implementation in this case. They can release source but it's the content that makes a game. Of course when ID opened their engines they had equivalent games come out and found themselves competing with their own product. Wait a minute, that never happened.

Re:FOSS games

[try_anything]

I guess I did beg for that objection by saying "source code" instead of "source," but I wouldn't consider a game "open" without the content. If you can't reproduce the game, then you haven't open-sourced the game, just the game engine.

Re:FOSS games

[G Morgan]

Out of interest do you consider RHEL to be OSS. It has non distributable art work as well that has to be replaced before the product will work (admittedly much less and many/most sections of the product will work perfectly without their copyrighted art work).

I think a hard separation between source and artwork makes sense. I'd be more interested in the tools than in a particular use of them and I don't think art work can often be done well in collaboration (at least not in the bazaar sense). In either case we gain the benefit of being able to run the game on Linux and access to a game engine for those who want to make a game. Can't be a bad thing.

Re:FOSS games

[try_anything]

I think a hard separation between source and artwork makes sense.

"Source" and "artwork" are overlapping categories. I'm not sure how you meant to draw the distinction, but I would say that the "source" of a game is everything that is required to build and run the game, except for elements that are contributed by third parties: compilers, libraries, OS, etc. If a game's artwork is withheld, then the game can't be re-created.

As for RHEL, I wouldn't call it 100% open-source, but I would give them partial credit depending on how much you can get running for how little effort. It's probably just a matter of a few branding elements that could easily be replaced by generic gifs without degrading the experience.

You won't get good games until you get marketshare

[nweaver]

This is irrelevant to the gaming front.

The limit to games on Linux is market share. Its not (much) easier to develop a good 3D game for linux as it is Windows, so why code for 2% of the market when you can code for 92% of the market?

Thus you will only get games where the developer has gone out of their way to ensure complete portibility and provides a port mostly out of courtousy.

The scheduler details are irrelevant for this: what Linux Games need is 10%+ marketshare on the desktop.

Should it matter?

[Jeremi]

I would think that 3D games would be considered a 'real time task' (i.e. you must draw the next frame within 1/30th of a second or else it won't look right), and therefore you would want to run them using the real time scheduler (SCHED_FIFO or SCHED_RR). Given that, it wouldn't much matter what fancy scheduling algorithms the non-real-time tasks were using.... your game would always get the cycles it needs when it needs them (up to to the CPU's capacity, of course).

Perhaps people just don't want to run their games as root though....

Re:Should it matter?

[Compholio]

I would think that 3D games would be considered a 'real time task' (i.e. you must draw the next frame within 1/30th of a second or else it won't look right), and therefore you would want to run them using the real time scheduler (SCHED_FIFO or SCHED_RR).

Absolutely not, you want your games to have a high priority but not that high of a priority. Real time tasks have a high potential for locking up the system, if there's a bad loop in a normal priority application then you can stop it - if there's one in a real time priority application then you have no way to spawn a task to stop it. In a perfect world this would obviously not be a problem, but play a few games and you'll see that it is a problem. I have found many games that lock up Windows will do Bad Things(tm) in Linux but at least you can still stop them without rebooting.

Re:Should it matter?

[Kjella]

I think the difference between hard and soft real-time has been discussed countless times. My impression at least was that the penalty for making the guarantee is so great, you normally only want to use it if you REALLY need it, like say a capture application that must capture or the frame is lost. In any case, I think IO priority is more important these days. With multi-core I've found myself also multi-tasking a lot more, but having some background IO task running is usually devastating to real-time IO. Yes, I know about ionice but...

Re:Should it matter?

[pla]

I would think that 3D games would be considered a 'real time task' (i.e. you must draw the next frame within 1/30th of a second or else it won't look right)

Once upon a time, that more-or-less held true. Games would poll the input, do some internal work, then refresh the screen; rinse, wash, repeat. The game behaved as sluggishly as its maximum frame rate allowed, regardless of which part of the game limited that rate.

Modern games have almost no hard connection between internal game state and the FPS. They perform all their core functionality as needed, and update the screen asynchronously as fast as available resources permit. If the engine has too much to do for a while, the frame rate drops accordingly (you can see this most obviously in many games immediately after loading a level, when the screen updates look very jittery for a few seconds).

So no, you really don't need (or even want, since "realtime" usually means the process can preempt even otherwise-critical system tasks) games to run as realtime processes. Ironically, you don't even want to run them above normal priority, because you'll find in some cases the game will actually run slower as other processes go from well-behaved to I/O bound (especially when the game depends on other processes for some of its activities, such as input, rendering, and sound).

Re:Should it matter?

[Lehk228]

PLEASE tell me you were going for +5 Funny with that.

Re:You won't get good games until you get marketsh

[Zironic]

Sounds like an evil circle.

To get Market Share you need games.
To get Games you need Market Share.

Re:Hmm

[Anonymous Coward]

The CFS (Completely Fair Scheduler) won't, but maybe the new FCS (Flux Capacitance Scheduler) might. Or already did.

Modular Kernel

[jshriverWVU]

One of the reasons I like the linux kernel is because it's very modular. Why can't both schedulers be included in the kernel, and the person compiling the kernel set which one they want? Kinda like how you could select between Alsa or OSS, or a myriad of other feature that are different but serve a similiar purpose?

Re:Modular Kernel

[TodMinuit]

There's no reason you can't go to the mans website, download the code, and then compile it into the kernel. However, including it in the kernel by default, even as an option, means that it must be maintained and cared for.

Re:Modular Kernel

[intx13]

Linux is like a car... :) A tail light or the license plate might be mostly modular, but the drive train isn't. The scheduler is very fundamental to the kernel, and must be running at all times. No doubt a system could be devised to make it work, but the pointer that Linus and others have been trying to make is that the most important reason for selecting one scheduler other another at this time is the dedication of the scheduler's maintainer and developer, not whether 3D games experience a slight decrease in performance. Even if they *could* both be used, Linus would still stick to his guns, because he believes that the developer behind the project is more important than the project itself.

I tend to agree - open source is driven by developers (developers developers developers!) - if the selected scheduler happens to be a bit slow for 3D games, someone will patch it, and the maintainer will integrate the patch. However if there aren't many active developers working on the project, and the maintainer doesn't seem dedicated, then it doesn't matter how great the code is right now; some time down the road work will be needed, and then the project runs into trouble.

In the open source world it's easier to patch up a slower design in a well-supported project than have to fork or reorganize an entire project because of lacking support.

Games.. only thing keeping me from linux full-time

[brxndxn]

I've used linux quite a bit before.. but it is always stuck on a 2nd or 3rd box I have around. I love the new Ubuntu...

except.. gaming support on linux is shitty. The games I have run on linux worked okay - but it took hours to set them up properly. Unreal Tournament 2003 is the last one I played on linux that had a linux port available..

I play games about 10% of the time I use my computer.. nonetheless, bad gaming support is what keeps me from using Ubuntu 100% of the time. I do not feel like having 2 operating systems intalled on my computers.

I'm not a 'gamer' by any means.. but games are important enough to me to keep me using Windows.. I would love to switch.. but I'll switch when the linux coders decide to push for a more compatible gaming system.

Re:You won't get good games until you get marketsh

[TodMinuit]

The limit to games on Linux is market share. Is this really true? Most major games are written using pre-made engines like Unreal, which typically are cross-platform. If they're hand-rolling an engine, making it cross-platform is rather easy compared to, say, a UI application. Games don't exactly use a lot of platform-specific coding technicals.

Strange, I've been gaming in Linux for years.

[DaedalusHKX]

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.

Re:Strange, I've been gaming in Linux for years.

[ben there...]

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. Doom 3 is a native Linux game, as are most, if not all, id Software games.

I get a few FPS more in RTCW: Enemy Territory in Linux (natively), though I generally have fewer background apps/services running than in Windows. But that's just an old game that I still like to play. I'll have to see how the much higher spec'd ET: Quake Wars handles when it comes out.

Re:Strange, I've been gaming in Linux for years.

[Hatta]

if they can run in WINE that fast, I wonder what a direct Linux implementation would do.

Wine really isn't an emulator, so there shouldn't be that much overhead.

Re:Strange, I've been gaming in Linux for years.

[plague3106]

Hmm, I'm bit skeptical of your post, mainly because Doom 3 and WOW DO have native linux ports, so I'm a bit suprised that you'd attempt to run them under Wine.

Re:Strange, I've been gaming in Linux for years.

[zippthorne]

Wine is not good at contractions, either.

Re:Strange, I've been gaming in Linux for years.

[T-Ranger]

At least when it first came out, Doom3 under Wine was faster then the "native" Doom3 for linux. The port was quick and dirty, with all the inline ASM stuff not handled by GCC, so it was dropped. Doom3 under Wine, compiled with the VC++ (I guess) compatible ASM inlines was faster. That said, I still play(ed) the native version.

Lots of the development tools built into the doom3 executable didn't work at all under Linux, either. Not sure if they did under Wine at day 0, or if they do at all today.

Re:Strange, I've been gaming in Linux for years.

[Nasarius]

WOW DO have native linux ports

Uh...no. WoW does run nicely under Wine, but that's not a port.

Re:Strange, I've been gaming in Linux for years.

[Stephan Seidt]

Performance improvements could come from i.e. unsupported and thus unvirtualized eye-candy DirectX features which would have a negative impact on performance under normal circumstances. Anyway, afaik all the mentioned games have OpenGL renderers, but I assume that you use the stanard DirectX renderer in World of Warcraft.

On the other hand, performance drawbacks because of wine's virtualization are very small but naturally they do exist. Adding an extra layer of wrapping takes time. Of course, maybe wine's handling of win32-specific calls and systems is more efficient than Microsoft's implementation in their operating systems ;-)

Re:Strange, I've been gaming in Linux for years.

[Anonymous Coward]

You want desktop Linux?

No, not really. Don't see the point really. The commercial OSes just work, and work well. Especially for gaming.

Then make it your desktop.

No thanks. I'd rather spend my time doing things other than OS tinkering, and I'm perfectly willing to pay others to do that for me.

Have fun kludging together some nightmare Linux system to hypocritically run Windows software on. I'll just run Windows, no biggie.

Re:Strange, I've been gaming in Linux for years.

[hey!]

Well, the issue at hand here isn't throughput, it is consistency.

An efficient scheduler gives processes in general the most bandwidth. A fair scheduler gives processes in a priority class the most equal bandwidth shares. A real time scheduler gives any given process the most predictable wait for bandwidth.

Each of these notions is somewhat different. Achieving a high frame rate over the course of a test on an unloaded system tells you nothing about the scheduler, other than perhaps it is not truly awful. On a moderately loaded system, the scheduler may be giving your game more than its share of CPU time, but if from time to time your game seizes up for a fraction of a second, it would be an irritation, even if on average it's getting enough bandwidth to give you a good playing experience. At the same time, this situation would be fine for data processing applications like image analysis, where an operation might take several seconds, or even minutes to complete. As long as the process gets plenty of cycles over the course of the operation, it's ok, even though your operation might have "frozen" for up to a second in the process.

Re:Strange, I've been gaming in Linux for years.

[WaXHeLL]

WoW has a MacOS port, not a linux port.

Semantics

Re:Strange, I've been gaming in Linux for years.

[vtcodger]

*** I wonder what a direct Linux implementation would do***

A perfectly reasonable question, but the answer may well be "about the same". The NE in wiNE istands for "Not an Emulator". In a sense, WINE *IS* a native Linux graphics implementation albeit aided or hindered by using the Windows API interfaces. If I recall the WINE documentation correctly it says that WINE is sometimes faster than Windows on the same hardware and application and sometimes slower.

Here's a link http://linuxhelp.blogspot.com/2006/02/wine-vs-wind ows-xp-benchmarks.html that seems to say roughly the same thing.

Re:Strange, I've been gaming in Linux for years.

[DaedalusHKX]

Nah, its a full time system, running everything from apache, samba, vsftpd, dns and network time in the background, gaim (pidgin now) browsers, a couple of reader tools and iptables (custom rulesets because of the gaming aspect). It is the service system for my work laptops. It just happens to serve as a gaming rig because it is the only really powerful system I got anymore. The laptops are all Turion 64's running Gentoo and BSD. This is the only one still running windows, and it is having far too many problems with the power saving... something the Linux rigs have no issues with. Curious that (its an HP, and I've found other ppl losing their network when returning from standby, MS and others have articles on it, nobody's fixed it, but thankfully, Linux and BSD don't suffer from any of those issues :)

Actually the only thing I'm saying is that (especially in response to the AC above saying "no thanks" is EXACTLY THAT... if you want it, DO IT... if you don't want it, then why bitch?) Wanting something hasn't stopped me from DOING it in my life, and every time I looked back at something where I hesitated, the only thing there is regret... regret because fear or laziness beat me. We are a culture of majority because hiding in the majority comforts cowardice. Doing your own thing is hard, difficult, nigh impossible in today's fear driven culture, even more so than in the fear driven cultures of the kings and queens of the past. If you don't plan to stand on your own feet, all I'm saying is "stop expecting to stand on someone else's shoulders"... corporations won't save Linux anymore than they "saved" BSD... neither will governments (which, if you translate their charters using Black's Law Dictionary, you'll find that governments are STILL corporations). BSD was saved by the fact that people believed in it, just like religions, just like windows "ease of use" (tell that to my father and his friends, to whom anything beyond punch cards is "difficult" and "clumsy interface", he hates Linux, Windows, BSD, MAC OS, and anything beyond the old CP/M).

As far as I'm concerned, Linux works as much as windows does (I simply feel it is better for me)... each has equal rewards for your trouble. If you get more involved with your own needs and desires, you get more out of it, if you expect someone else to solve it, you get what you deserve, working your days away to pay someone else to fix your rig and do a half assed job of it (I worked IT for someone else before running my own business the way I wanted to, so I can attest that if you do a thorough job, you can't finish as many customers, and won't get as much return business from the same client, and someone else gets the promotion and the raise)... so in the end, you get the proverbial shaft. This has been the case since people started importing food while living on farmland, and voting for someone else to send someone else's kids to die in wars of someone else's making and demanding that other people pay taxes so they could benefit (healthcare, cops, zoning) from the robbing of those people of their efforts (wages/profits) and their property (land through zoning). I call it just deserts and, for one, will have no conscious part of it. What each of you choose for yourselves is your own thing :) I'm just here to rile up the mud to see if there's any precious gems left among the chaff.

Re:Strange, I've been gaming in Linux for years.

[DaedalusHKX]

Yeah, but I had the benefit of having bought the commercial edition (CD, windows, mostly because I support ID's choice to make them posix friendly/compatible). I didn't have the patience to download the hacks at the time, so I just tweaked it for WINE, about 5 minutes of "hard" work. And about 95.00 USD saved for other expenditure :) instead of paying some drone at the local compushop to tell me they have no clue, because they don't use "Lie-nax".

*chuckle*

So yep, it is against my principles to pay for anything I don't need or want :)

Re:Strange, I've been gaming in Linux for years.

[12357bd]

I wonder what a direct Linux implementation would do. I just love seeing folks buying the headlines instead of blazing their own paths.

Yes, that's teh point. What I want (unrealistically by now, i know) is linux only games. Attract gamers to linux not linuxers to games.

Re:Strange, I've been gaming in Linux for years.

[init100]

Have fun kludging together some nightmare Linux system to hypocritically run Windows software on.

Why is it hypocritical to run Windows games on Linux?

Re:Strange, I've been gaming in Linux for years.

[init100]

It is still a wrapper that converts Win32 API calls to their Linux counterparts. That takes time, although not a whole lot of time.

Re:Strange, I've been gaming in Linux for years.

[totally bogus dude]

Moreover, where do you draw the line between it being a "Windows" game or a "Linux" game if it can run on Linux? Java is considered cross-platform, because the same binaries can run under a JVM on different platforms. So, why wouldn't WINE be treated the same - a kind of VM platform for Win32 applications?

Re:Strange, I've been gaming in Linux for years.

[Lesrahpem]

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.

I've noticed the exact same thing about running games in Wine, as well as when comparing the Windows and Linux versions of Unreal Tournament 2004, Unreal Tournament GOTY, and Enemy Terrirtory. I think the main reason has do to with how Linux manages memory and system resources compared to Windows. Also, there's no Windows equivalent to running an X session with JUST a single game running inside of it, which helps out a lot when I'm tyring to run a game on my computer which is made with better hardware than I have in mind.

Along the same lines of discussion, I've noticed that nVidia graphics cards perform better under Linux than Windows. I've tested this not just from playing 3D games, but also doing heavy 3D animation with Maya.

Re:Strange, I've been gaming in Linux for years.

[totally bogus dude]

The post which originally claimed it was "hypocritical" only mentioned Linux, and not FOSS. It's perfectly possible for someone to like and use Linux, and not care about the Free software philosophy; in the same way it's perfectly possible for someone to use Firefox on Windows because they prefer it to MSIE or Opera, and don't care that it's Free. There's absolutely nothing hypocritical about that. It's also not hypocritical to prefer or even "believe in" Free software, but be willing to use proprietary software when it's the best choice (that'd be pragmatism). It's not even hypocritical to do that, while still hoping for (or helping to create) a Free alternative to the proprietary software. But, you already know that (unless you actually don't have any idea what the word hypocritical means).

Secondly, it isn't necessarily illegal to make an "emulator" (which WINE isn't, technically, although it's used like an emulator would be) for the Win32 API. After all, there is a commercial entity (Cedega or something?) involved in WINE, and they haven't been sued into oblivion; presumably, if they were actually doing something illegal, they would have been shut down. I mention this as a commercial example because it's feasible some companies wouldn't bother trying to stop technically illegal activities carried out by free software people, on the grounds of it being too difficult a target. Businesses are another matter.

Even your apparent claim that the PC games market wouldn't exist if it weren't for Windows is absolute bunk. Games existed before Windows and on various platforms. If the PC OS market wasn't so heavily dominated by Microsoft, but instead had fairly even splits between 3 or 4 different platforms, then PC games would routinely be designed cross-platform and released across all major platforms. Not doing so would be stupid. There's nothing magical about Windows which allows it to run games. It's purely market share that results in developers ignoring other PC platforms, just like some developers choose to develop for a specific console. Market shares are subject to change.

Overall, I'd rate your troll about a 7. Not a bad effort at all.

Re:Strange, I've been gaming in Linux for years.

[DaedalusHKX]

I just posted about something like this elsewhere in the thread.

Not only do the cards do better in Linux, but the various IDE chipsets do remarkably well, especially in nVidia's case where they recommend using the MS drivers unless you want software RAID... I've had similar results with the ATI IXP chipset's IDE controller. It has major issues with networking, power saving, etc. Put it under Linux, and the problems just ... go away. Strange that. Commercial companies can't be bothered to write good drivers anymore, but a bunch of geeks, paid or unpaid, can. Sad day in the unFree market.

Re:Strange, I've been gaming in Linux for years.

[renoX]

[[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.]]

Weird: games framerate are mostly dependent on the driver, and Nvidia or ATI have put much more effort on their Windows driver than on their Linux driver..

I'd say that either you have a problem on your WindowsXP configuration (a virus or an antivirus which suck CPU or a configuration problem, have you the latest version of the driver for your video card on WindowsXP?) or maybe the settings of the game are not exactly the same on both OS..

Re:You won't get good games until you get marketsh

[nyctopterus]

One reason (probably why you can find games for macs): you'll have far less competition. Having 50% of 2% of the market is better than 0.5% of 100%. While the Linux gaming market is small, it's pretty unsaturated. There's got to be other reasons for lack of gaming on Linux.

Pluggable

[cerelib]

That is why Linus should have listened to Con Kolivas when he tried to introduce a pluggable scheduler system. With a modular system we could have CFS and the staircase scheduler and both problems solved.

Re:Pluggable

[andrewd18]

Linus has already explained why he doesn't like the idea of a pluggable scheduler system. See http://kerneltrap.org/node/14019

Re:Pluggable

[KZigurs]

ever changed cam-belt while doing 120mph on a highway?

Multiple choice schedulers

[davidwr]

Personally, I'd like things like schedulers to be pluggable. But that's just me. Or maybe not.

Re:Multiple choice schedulers

[Anonymous Coward]

Try again.

No, it isn't

[everphilski]

Because the 0.5% of 100% has a much greater potential for growth ... pump up the advertizing, work up some new expansions/tie-ins/etc. and build your market share. The 50% of 2% has stagnated.

Scheduler Nanokernel

[Doc Ruby]

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.

Re:Scheduler Nanokernel

[intx13]

Well, at a certain level, that's what the kernel is. The problem is that providing the bare minimum of hardware access to userspace means that anybody can do naughty things to the hardware. Remember drivers in Windows 98? Linux has the "best" of both worlds. For the desktop, the kernel can contain lots of APIs and kernel-land drivers, providing fast hardware access and high level interfacing with security from crashes... and for embedded systems you just compile your own kernel and link in whatever you want. Distributing Linux is pretty easy as is. Most of the time you don't want the ability to load and unload core kernel components on the fly, just like you wouldn't want to swap out the ALU from the silicon inside your processor while your computer is running. And if you wanted to customize at that level, just download the source and compile away!

Re:Scheduler Nanokernel

[Doc Ruby]

That's what a kernel is, but not the Linux kernel. Linux is a monolithic kernel, including all kinds of stuff that isn't the scheduler, isn't the driver API (or just the drivers too). That's why Torvalds correctly said that the scheduler is a tiny part of the kernel.

If customizing Linux to the specs I mentioned were so easy as downloading source and compiling (you skipped the hard part, factoring and looping back the extra codepaths), then all the distros that try it (probably starting with the "Linux on a - 1.44MB - floppy" ones in the mid 1990s) would be trivial. But they're not.

FWIW, while I don't want to swap out my ALU HW, many recent advances in CPU take exactly that approach, like the Cell sacrificing CLU die space for extra ALUs and parallelizing HW. In point of fact, one reason I'd like a nanokernel would be to run on something like the Cell with embedded (or just Tbps-bus-bridged) FPGA. Linux's current architecture is far from serving that architecture.

Re:Scheduler Nanokernel

[nuzak]

That's called a nanokernel. And you don't even need the scheduler in kernel space either -- the whole notion of "processes" is not something the OS necessarily has to concern itself with. All a nanokernel has to do is make hardware available on demand.

You can more or less engineer the kernel concept out of existence until it's nothing but an interrupt handler and a call gate. However, since the reality of commodity CPUs is that they're designed with hardware contexts and even C stacks (or perhaps I should say Pascal) built-in, there's really not much reason to keep it completely out of kernel space on such hardware. This doesn't argue for Linux's extremely monolithic nature (it doesn't even have a proper VFS layer) but it does mean that at some point, further reductionism is just absurd.

Making the scheduler pluggable would just make sense though.

Re:Scheduler Nanokernel

[nuzak]

> That's called a nanokernel.

Eh-heh... I suppose since the subject of the post contained the word "nanokernel", that that was kind of redundant. :P

Re:Scheduler Nanokernel

[dpilot]

Since we've run the spectrum from kernel to microkernel to nanokernel...

What are the characteristics of a picokernel?
Or is that what you'd call an interrupt handler and a call gate?

Re:Scheduler Nanokernel

[nuzak]

> What are the characteristics of a picokernel?

No such thing that I've heard of generically (though picokernel is a trademark of an RTOS vendor). But embedded applications on MMU-less platforms can and do dispense with the OS altogether .. or you could say the app is the OS.

Re:Scheduler Nanokernel

[Chris Burke]

Everything else, including IPC, could be in userspace.

And the user-level application process communicates with the IPC process to do IPC with some other process... how?
Some things, even in microkernels, stay in the kernel out of necessity. I'm not saying you can't have user space IPC libraries, but fundamentally the act of two processes with separate memory spaces communicating requires OS involvement.

Re:Scheduler Nanokernel

[Doc Ruby]

Not necessarily. There is a case that VM must be mediated by a privileged OS, or the memory spaces aren't really separate. But the IPC itself can be in userspace. Consider how much already is: shared text config files. Databases. Network sockets, except for the access to HW. Why can't a userspace process accept messages from processes addressed to other processes subscribed to the daemon? Even secure IPC can be in userspace, with app-signed tokens.

Re:Scheduler Nanokernel

[dpilot]

Years ago I picked up a book on "XINU" that was kind of like that. There wasn't really an OS, you linked OS components into an application that was loaded onto the hardware.

As for the picokernel thing, I was more playing on the words. We obviously passed over millikernel too, not to mention decikernels and centikernels.

Related to that in the literary realm, we've all been hearing about nanotech for years. I've working in sub-hundred-nanometer silicon for several years now, so I guess nanotech is getting a little passe'. I'm now reading Ray Kurzweil's "The Singularity Is Near" and I saw the term "picotech" for the first time. Around that time, I also read the SF book "Hauling Ice" where they threw in picotech and femtotech. Gotta keep up with the Joneses.

Re:Scheduler Nanokernel

[Alef]

As far as I know, with nanokernel you usually mean a kernel in which even the scheduler not included. For example, you could have an OS running multiple schedulers at once. (Perhaps that is why you called your suggestion a "Scheduler Nanokernel"...?) See for example the Wikipedia article on nanokernels. Exokernels is a similar concept.

Re:Scheduler Nanokernel

[Chris Burke]

Well that's what I mean. You can have whatever complexity of IPC protocol implemented in a user-space daemon. However for Process A (an application) to tell Process B (your IPC daemon) that it wants to do IPC, requires some form of IPC in itself. The kernel by necessity must be involved. Getting that data to Process C (the target of Process A's message) requires kernel-supported IPC between B and C.

That's always been the performance problem with microkernals. Since the services are all in user-space but in separate processes, in order for an app to use a service there's first the context switch into the kernel, then the context switch to the service, then back to the kernel, then back to the app. As opposed to macrokernels where you switch to kernel space then back, half as many context switches. Shared data through text files is a good example -- in a microkernel, your file system is a user-space service, and the kernel is responsible for connecting your application to that service via IPC, and more hoops must be jumped through than in a kernel-based file system driver.

Microkernels are still great due to the compartmentalization and its many advantages, which is why Mach is still a very popular research OS. It still isn't practical or even possible to take the philosophy to the extreme and get rid of all kernel-based services.

Re:Scheduler Nanokernel

[Schraegstrichpunkt]

You might be interested in the L4 microkernel.

Re:Scheduler Nanokernel

[Doc Ruby]

I had been watching L4 for several years until about 2005, but it developed too slow.

March 2007
        TUD:OS/DROPS available via SVN
        The repository has been migrated to SVN.

19 Oct 2005
        L4.Sec Reference Manual available
        The first draft of the L4.Sec Microkernel Reference Manual has been made available. Please refer to the L4.Sec site.

All they've announced in over a year and half is migrate the repo to SVN. I was right to stop watching their paint dry.

Now, a microkernel Linux with userspace modules that runs Linux apps would be good, and develop much faster. But since Linux apps call syscalls, which the kernel would have to accept even as just a proxy API to userspace kernels, and that swapping would ruin any performance gains, such an architecture is probably merely academic.

Re:Scheduler Nanokernel

[Geoffreyerffoeg]

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.

Go write it. It would be pretty cool if we had a new kernel that's Linux-compatible for userspace apps, but is designed as a microkernel.

Setbacks?

[ichigo 2.0]

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.

Linus mentioned somewhere that CFS and SD are both superior to the old scheduler, so in what way can choosing CFS be considered a setback?

Seems like Linux / FOSS should be focusing on...

[MeditationSensation]

...something more probable, like making GIMP a killer Photoshop clone or something. Games is just such a competitive and tricky market, and I wonder if there would really be that many Linux people willing to pay for them. Seems like many Linux people in the desktop space are high school and college kids.

Games and VS

[everphilski]

Games and Visual Studio (10%, 75% respectively). Even the freebie versions beat the crap out of any IDE I've seen for linux. Yes, I've used Eclipse and the other major players...

Re:Games and VS

[CuteAlien]

Maybe it's simply because you are used to it. I worked for very long nearly exclusively with VS (since VS 1.5), but worked with Code::Blocks and the command-line in the last year. At first it felt horrible, but I started to love a few things after a while. Now I have to use VS for a new project and switching back to it just felt horrible once more. Not sure yet if I will adapt again...

Re:Games and VS

[everphilski]

I tried code::blocks about 2 years ago, I wasn't a fan. Can't remember my exact complaint ... when I do have to program on Linux, I generally use gvim and a terminal to 'make'.

Re:Games and VS

[Abcd1234]

Even the freebie versions beat the crap out of any IDE I've seen for linux.

Tell me that again after VS has crashed for the second time in a day, or mysteriously added new connection strings to your project resources for no apparent reason, or decided, once again, to reorder the code in your designer file, generating massive conflicts when you update your local source tree, or strangely repositioned the scrollbars when you opened up a dataset and started navigating, or...

Honestly, VS is good, for what it is. But at the same time, it's an unstable, unpredictable piece of crap. Which pretty well describes most MS software, so I suppose that's not terribly surprising.

Re:Games and VS

[everphilski]

Tell me that again after VS has crashed for the second time in a day, or mysteriously added new connection strings to your project resources for no apparent reason,

Can't say I've ever had any of those problems...

or decided, once again, to reorder the code in your designer file, Ah. Dude. Seperate your presentation from your logic (model-view-controller, etc...). Your designer file should **just** have UI code in it. Theres regions for the machine based stuff and regions for the person-generated stuff. Keep the person-generated stuff to a minumum. Again, I haven't come across that problem...

generating massive conflicts when you update your local source tree, or strangely repositioned the scrollbars when you opened up a dataset and started navigating, or...

Again, I can't complain. I use C++ and C# ... never had any serious problems with them.

Re:Games and VS

[Abcd1234]

Can't say I've ever had any of those problems...

Apparently you're lucky.

Your designer file should **just** have UI code in it. Theres regions for the machine based stuff and regions for the person-generated stuff. Keep the person-generated stuff to a minumum. Again, I haven't come across that problem...

Did I say I added human-generated code? No. That would be stupid. VS just decides, on a machine-by-machine basis (ie, it's largely deterministic on one box, but another box can produce a different ordering... god knows why), the order in which code will be laid out in some of it's generated files. This includes designer files, where a small change can completely reorder the code for no apparent reason, and XSDs (this one is particularly irritating). Why they didn't just use alphanumeric sorting, I'll never know...

Again, I can't complain. I use C++ and C# ... never had any serious problems with them.

Then you've never worked on a reasonably large dataset in VS.

Re:Games.. only thing keeping me from linux full-t

[Stringer Bell]

I'm not a gamer at all, but for years I've said that Quicken was the only thing keeping me from switching Linux full-time. (Yes, I know there are FOSS bookkeeping packages out there. Quicken is excellent, though, so any switch is a step down in my mind.)

Then I realized it doesn't matter which operating system I run as long as I can do what I need to do. I was only trying to switch to Linux for ideological reasons, not for any practical reason. The act of switching over was going to involve a lot of time, effort, and possibly expense, and if there was no "business reason" to go through all that, it would largely be for nought. If I had a mission-critical app I needed to run that only ran on Mac or Linux or whatever, then I'd switch, but I'd have to jump over with both feet. I don't want my music, pictures, documents, finances, etc., spread all over multiple machines (or multiple partitions of different types.) My mission-critical app is Quicken...so I continue to run Windows.

So don't look at it as "I'd switch over completely, but..." Instead, look at it as "Apps drive the OS I use. I need the following app(s): ________, which is/are well supported on _______, so my OS is ________."

Re:Modular Kernel GREAT QUESTION jshriverWVU

[Anonymous Coward]

"One of the reasons I like the linux kernel is because it's very modular. Why can't both schedulers be included in the kernel, and the person compiling the kernel set which one they want?" - by jshriverWVU (810740) on Tuesday July 31, @12:28PM (#20059031)

Great question, jshriverWVU!

( & though I am MOSTLY a "Win32 kind of guy", I am curious myself on this note you bring up, also!)

Hey, Penguins? Since this OS comes with source? Why not allow users this choice for Linux OS installs @ setup time (the ability to choose between SD scheduler (Con) & Completely Fair Scheduler (Ingo))...??

APK

P.S.=> I am personally SURPRISED that Linus Torvalds did NOT include this as an optional build you could install (a "gamer's & multimedia person's core/kernel" in essence) @ setup time for Linux, because it IS doable (kind of like how NT-based OS can install a singlecpucore build, vs. a multicpucore build)...

Maybe, JUST MAYBE? This does point to some "egomania" & personal like/dislike stuff on the part of Mr. Torvalds (favoring Ingo OVER Con etc. et al)... who knows, except those 3 people, & L.T. most of all! apk

You didnt read TFA

[everphilski]

CFS actually beat out the outcast scheduler ...

Re:You didnt read TFA

[Chandon Seldon]

Beat out at *framerate*, which isn't the same thing as responsiveness, although those two things are generally positively correlated.

The numbers that would really help in this argument are things like "standard deviation of inter-frame delay". If you can come up with a good way of measuring that, that'd be great.

Re:You didnt read TFA

[cerelib]

It's not about which of the two is better. What a pluggable system provides is a way to further customize the performance of the Linux kernel to suit the application. Different users have different needs. I am sure some developer could figure out a scheduling algorithm that would be great for games but horrible for many other uses.

Linux and Games

[CopaceticOpus]

I've figured out how to get games running with Linux!

1. Set up your Linux system. Use onboard video and don't overspend on your processor.
2. Buy a PS2, a Wii, or a 360.
3. Play games on your game console and do everything else on Linux.

Re:Linux and Games

[TemporalBeing]

I've figured out how to get games running with Linux!

1. Set up your Linux system. Use onboard video and don't overspend on your processor.
2. Buy a PS2, a Wii, or a 360.
3. Play games on your game console and do everything else on Linux.

Well..there is a simpler way...
Buy a Wii or PS3. They both run Linux and do games without any modifications necessary. ;-)

Re:Linux and Games

[Orochimaru]

I hate dual booting and buying a console seemed like the obvious solution to fulfilling my gaming and Linux needs. Unfortunately, while I love my Wii, PC gaming is just too good. I tried Cedega for a while, but poor performance, problems with the graphics in most newish games and the arcane incantations required to get said games running makes this a worse option than dual booting. Games like Unreal Tournament 3/4 and Quake 4 which run beautifully on Linux give me some hope for the future which otherwise looks grim for the Linux gamer.

Re:Linux and Games

[shutdown -p now]

4. Kiss goodbye to all the excellent PC games which will never be ported to any console because of the latter's inherent limitations.

Re:You won't get good games until you get marketsh

[ucblockhead]

People seem to forget that someone actually tried to build a company on Linux games. It was a disaster. The trouble wasn't the OS. The games ran great. The trouble was that no one (but me, I guess) bought them.

Re:Modular Kernel GREAT QUESTION jshriverWVU

[McNihil]

Its typical in Zonk's topics that something like this gets 0 as mod point.

As you said choosing scheduler can be done in kernel building so all this mud flinging is assanine IMHO and just shows how little so called gamers know what Linux is capable of.

Be glad they chose CFS over SD then.

[delire]

Sayeth Kenneth.

Alright, Just got done with some testing of UT2004 between 2.6.23-rc1 CFS and 2.6.22-ck1 SD. This series of tests was run by spawning in a map while not moving at all and always facing the same direction, while slowing increasing the number of loops.

CFS generally seemed a lot smoother as the load increased, while SD broke down to a highly unstable fps count that fluctuated massively around the third loop. Seems like I will stick to CFS for gaming now.

--
Kenneth Prugh

Sayeth Matthew

My experience was quite similar. I noticed after launching the second loop that the FPS stuck down to 15 for about 20 seconds, then climbed back up to 48. After that it went rapidly downhill. This is similar to other benchmarks I've done of SD versus CFS in the past. At a "normal" load they're fairly similar but SD breaks down under pressure.

The only other thing of interest is that the -ck kernel had the WM menus appear in about 3 seconds rather than 5-8 under the other two.

The only chap that says otherwise doesn't post his results.

From TFA

Re:Be glad they chose CFS over SD then.

[Anonymous Coward]

It's true that the two sets of test numbers (three if you count Ingo's) show CFS is better in terms of raw FPS, but it's not clear that these numbers demonstrate "3D performance under load". My impression of CK's work was that he was striving for improved user experience over raw performance, and if SD is indeed better in this way, then more tests are needed to quantify it. For example, the user experience in a game will be better if the computer's response is smooth; a game running at a smooth 50 FPS is better than a game that runs at 120 FPS for .75 seconds, then drops 30 frames for the next .25 seconds -- even though the raw FPS is much higher in the latter case. The test would be more informative if the FPS variance was measured in addition to the raw FPS, and during a demo sequence where the player is moving around rather than just sitting still.

It's also not clear that the "while" loops are a good representation of a background load, as they are constantly "on", but they don't do anything; they do not sleep early and they don't access other memory pages, network, or disk. A better load might be to start some long compiles, or have a web server serving pages to another machine in the background.

Re:Hmm

[monoqlith]

I think he needs more CSF (Cerebrospinal fluid) to nourish his brain cells and alter their troll-like behavior.

This was already a known issue

[Anonymous Coward]

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.

Re:This was already a known issue

[Anonymous Coward]

"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." - by Anonymous Coward on Wednesday August 01, @03:22PM

This is 1 of the things here, that SURPRISES me, here, the most:

Why won't builds of BOTH kernels (with the SD scheduler, & the CFS scheduler) incorporated into Linux distros from now on? This gives users the CHOICE of using either/or, for whichever BEST SUITS THEIR NEEDS & APPLICATION MIX BASE!

The other? Well, it doesn't REALLY 'surprise me', because it is a picture into the "uglies" of human nature & "politics"!

What I mean, & from my understanding reading here?

Well, that apparently Ingo Molnar supposedly really only "reworked" (using that term loosely, because it sounds more like he outright STOLE Con Kolivas' work really from what others wrote here) Con's algorithms to a large extent, & called it his own...

MAN: That's pretty sad, provided it IS true.

From the looks of it? It seems to be.

I.E.-> Ingo Molnar ONLY CREDITED Con Kolivas after the 'holler' went out when folks started looking @ his code, vs. that of Con Kolivas, & seeing many similarities in ideology/algorithm/design & technique (from what I have been reading here, which YES, I take with a grain of salt, but do NOT dismiss enirely, either).

Imo, @ least? Credit should go where it's due IMMEDIATELY (not only after others may have caught someone in the act of nearly literal code algorithm plagiarisms), not to those more "politically connected", but this?

This IS life, today & always. Soldiers win the fights, & fight them, but politicians get the credits in the history books.

APK

P.S.=> More of a "Win32 guy" here, but in the end? I have to say it again: This would make sense to me @ least, for the Penguin crowd to give L.T. a hoot via email, or whatever route, & ask for this as an option during installation (rather than having to perform kernel recompiles & code insertions etc. et al)... apk

Re:This was already a known issue

[Anonymous Coward]

Why won't builds of BOTH kernels (with the SD scheduler, & the CFS scheduler) incorporated into Linux distros from now on? This gives users the CHOICE of using either/or, for whichever BEST SUITS THEIR NEEDS & APPLICATION MIX BASE!

Another political issue. It was proposed, it was denied. A very small kabal knows what best suits our needs. If you don't like it, go fork yourself [your own kernel development]. That's the message I got, anyway.

Re:Modular Kernel GREAT QUESTION jshriverWVU

[SirTalon42]

Actually the quote from the in the summary from Linus is part of a larger email where hes dismissing the idea of using the plugscheduler (I can't seem to recall the exact name) that would make the CPU scheduler plugin based like the IO scheduler currently is. His reasoning against it were largely BECAUSE what they learned from having the IO scheduler plugin based and its something Linus as well as the subsystem maintainers DON'T want to repeat.

Anyways, you can still just apply Con's patch to the kernel to use his scheduler instead of the old scheduler (and if he keeps maintaining it, you'll be able to use SD instead of CFS). Don't forget that we haven't even had a kernel released using CFS!

Re:You won't get good games until you get marketsh

[plague3106]

For your theory to work, people would have to buy whatever crap game is put out. Put out a crappy game, and you'll not likely even get 50% of the 2% market.

Re:You won't get good games until you get marketsh

[Anonymous Coward]

People seem to forget that someone actually tried to build a company on Linux games. It was a disaster. The trouble wasn't the OS. The games ran great. The trouble was that no one (but me, I guess) bought them.

Huh, I thought it was because the CEO was embezzling the money?

Vague generalizations on OS suitability

[MSTCrow5429]

Windows is for games and office work.

OS X is for artists and people really into style.

Linux is for hackers and various niche environments.

Linux does not need to support gaming. Windows does that quite well. Anyone that wants to game can dual-boot with Windows, or buy a console. Linux will not support gaming, for the same reasons AIX or Solaris are not chock full of gaming goodness. It isn't required or desired, and the OS is far more suitable for other, often more "serious," applications.

Re:Vague generalizations on OS suitability

[garett_spencley]

Linux is for hackers and various niche environments.

While I agree that what I am about to describe can very much be considered a "niche environment", pretty much every single kernel developer develops Linux for his own desktop. Linus created Linux in the beginning so that he could have a full Unix-like OS on a 386.

So Linux' entire existence is for the desktop. It has proven to be a very great server OS as well. And a lot of people develop it for that purpose. But Linus himself, when responding to Con's claims of big money pushing server development away from desktop development was something along the lines of (paraphrased): "every single developer that I have trusted to maintain parts of the kernel run Linux on the desktop, care primarily about the desktop and I wouldn't want anyone who didn't run Linux on their desktop to ever touch the kernel".

Of course there is still the paradox. No games = no gamers. No gamers = no money for game developers = no games = no gamers and so on. But every one who has worked to made Linux what it is today wants to see it thrive on the desktop. So while your opinion is certainly valid and you're entitled to it. I don't believe that it is shared by the very people who develop Linux.

Re:Vague generalizations on OS suitability

[dave562]

I completely agree. Every OS has it's strengths and weaknesses. I see a lot of ego among Linux users and developers. They want their OS to do EVERYTHING under the sun. I'm a Windows guy primarily, but anything that I do that relates to computer security I do on Linux (Snort, nmap, etc). It's all about flexability and choosing the right tool for the job.

Re:Vague generalizations on OS suitability

[Necrotica]

Linux will not support gaming, for the same reasons AIX or Solaris are not chock full of gaming goodness. It isn't required or desired

That's an arrogant presumption and couldn't be further from the truth if Linux is to be successful on the desktop.

Re:Vague generalizations on OS suitability

[Anonymous Coward]

Linux will not support gaming, for the same reasons AIX or Solaris are not chock full of gaming goodness. Hm, what again was the reason for that... ah yes, they tried to avoid mass-market at all cost, right?

Re:Vague generalizations on OS suitability

[dave420]

... then linux will never be ready for the desktop, and will always be playing third-fiddle to Windows and OSX.

Re:Vague generalizations on OS suitability

[try_anything]

Linux is ready and running on the desktops of vast numbers of people. The "ready for the desktop" issue almost always means "ready for me to foist onto my unenthusiastic but technologically deferential friends and relatives," and it only matters to two mostly overlapping groups of people:

1. Linux enthusiasts who obsess over desktop market share because they're worried about the social acceptability and social prestige of a brand they're ego-identified with.
   
2. Linux enthusiasts whose understanding of the world is challenged by the continuing prevalence of Windows.
   

The survival of Linux is assured. The free software movement is chugging patiently along; it's far from the theorized tipping point where it snowballs and takes over the world, but that depends on corporate and industial uptake, not home desktop use. Linux provides a pretty decent desktop environment for those who want to use it. These days, it's easier to rid your home of Windows than to be a vegetarian.

The only hard thing is pushing Linux on people who don't want it. Who cares? Let them be.

Re:Modular Kernel GREAT QUESTION jshriverWVU

[Ash Vince]

Con has already said he will no longer develop it or any other kernel development because his scheduler was not chosen.

Re:You won't get good games until you get marketsh

[delire]

Is this really true? Most major games are written using pre-made engines like Unreal, which typically are cross-platform.

They might be cross-platform but they still cost 100's of 1000's of dollars to license. Game Engines top some of the most expensive proprietary software out there.

Moreso it is false to say "most major games" (my emphasis) are built from these engines. Quite a few are yes, but sometimes the technical baggage of the engine is so great - in that steers design directions - that it's cheaper in the long term for a game development shop to author their own engine in-house.

Furthermore you can't beat the freedom of being the legal author of what you use.

Even if you can afford to license an existing engine - or use a FOSS engine like QuakeIII - it's still an expensive and time consuming task to make the actual game. A good example is Half-Life 1: it was a direct architectural relative of Quake2 yet it still took years and costed millions in labour to make.

Programming and game-design aside, don't underestimate also just how long it takes to make the art.

any *more* setcbacks?!?!?!

[Bastard of Subhumani]

gaming on Linux can't suffer any more setbacks

In the same way that the pope can't get cervical cancer?

Re:any *more* setcbacks?!?!?!

[Anonymous Coward]

So is parent a troll for pointing out that the supreme pontiff of the Roman Catholic church is male or for suggesting there aren't any games on linux?

Re:You won't get good games until you get marketsh

[TheCRAIGGERS]

Ever heard of DirectX? While some of the engines that you mentioned may have the option of using OpenGL or DirectX, I don't think many hand-rolled engines do.

Re:You won't get good games until you get marketsh

[Chandon Seldon]

From what I've heard, Loki didn't die due to a lack of customers. They died because of personnel problems, and because their profit margin wasn't good enough to make up for their other shortcomings.

The past is the map to the future

[Danathar]

When there was more than one OS that ran on different HARDWARE, games could be differentiated and selling points could be made for buying an Amiga, or an Atari over the Mac and PC of the time.

Other than Security, to the average user who is using Windows there just is'nt the "Whoahh" that people used to get when somebody back then saw the Amiga or Atari. Compelling reasons just don't exist for the average user to switch from windows to LINUX except maybe fear of viruses and malware.

For games to take off on LINUX there needs to be a game done on LINUX for LINUX ONLY that everybody wants and does something on LINUX that CAN'T BE DONE on windows. When I saw what the Amiga could do commpared to the PC I KNEW why I wanted one.

Granted the Amiga was as much a hardware advancement as OS, but the point was the average user could understand why they needed it.

Re:You won't get good games until you get marketsh

[dvice_null]

Why not just write a cross platform game instead of a Linux or Windows game? It is actually easier than writing a DirectX game, because of the advanced libraries. Try writing a game with Irrlicht-library for example. You can even select whether to use DirectX or OpenGL as a rendering engine for the same code you write and it takes only about 20 lines of code to write a working program that will load a 3D-object from file and display it.

http://irrlicht.sourceforge.net/tut012.html

If you don't like Irrlicht, you can always use Ogre 3D or Crystal Space or even SDL with OpenGL.

Re:You won't get good games until you get marketsh

[Xtravar]

1. Linux machines
2. Development setup
3. QA
4. Support
5. Platform-specific APIs added to, say, make shortcuts or turn off screensavers or whatnot

Part of this can be solved by rogue developers, but not all. And believe me, once a developer is accustomed to the system, he'll realize his effort is in vain because no management would let him release untested and unsupported code, nor would management want to test or support something with so little ROI (return on investment). You could invest that money and time into something that will get you $, or you could invest that on something that will get you $$$$$ - it's just smart economics to work on the next Windows thing than the Linux thing.

If you start working as a developer, you will come to realize these realities someday.

Re:You won't get good games until you get marketsh

[blincoln]

There is also typically a lot of customization done to licensed engines by the licensees, at least according to my game dev friends. Even if the engine is more or less cross-platform out of the box, it seems unlikely that it will remain that way for long unless it's a specific goal of the developers working for the licensee.
Given how many complaints I've heard about the Unreal engine in general, I'd have to imagine that with the apparent headaches of getting licensed games to run right just on Windows and the 360, only a really dedicated game developer is going to target Linux as well.

The X Factor

[mcelrath]

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

Re:The X Factor

[DamnStupidElf]

As far as I know, using the Direct Rendering Infrastructure, 3D games are mostly independent from the X server process. LibGL ends up doing most of the work directly with the hardware via memory mapping within the game's process. I don't know how many of the calls need to go back to the X server, but my guess is only the ones dealing with windowing and user input.

Re:The X Factor

[renoX]

[[I don't know how many of the calls need to go back to the X server, but my guess is only the ones dealing with windowing and user input.]]

Well the GP was talking about pressing a key, so that's definitedly user input..
And the latency for the reaction to user input is quite critical for a game, but does the kernel --> X server --> games context switches induce really a measurable latency for a player?
I don't know..

Re:Modular Kernel GREAT QUESTION jshriverWVU

[dave562]

Screw you guys, I'm going home!

Re:Games.. only thing keeping me from linux full-t

[fishbowl]

"I'm not a gamer at all, but for years I've said that Quicken was the only thing keeping me from switching Linux full-time."

I actually prefer to run Quicken in a VM. I can backup the whole VM partition. I can run a version of Windows that's fully tuned to the application. It has a very small footprint. I've been doing this for almost ten years already.

I *greatly* prefer it to running it on a native Windows boot. I'd almost go as far as to say, if I had to run Windows, I'd probably start doing finances on paper.

The Scheduler That Lived will live

[microbee]

Both SD and CFS are superior to the old one. Between the two, the one that gets merged into mainline will be the best eventually.

There were a lot of testers when SD came out, because it clearly beat the pants off the old one, and that was exactly why Ingo went ahead to throw his own version of a fair scheduler - otherwise his code would not survive.

Which one is better, SD or CFS? Technically, it was hard to say, but it's not about technology - it's like the browser war, the one with the bigger market share wins. CFS has been merged into mainline and gets the biggest exposure, so there are hell a lot of more testers and developers attention, and with a genius like Ingo, it's only a matter of time that CFS will perform better than SD - the latter has been simply ignored since CFS was out.

So arguing which one is technically better is not the point. It's like people kept arguing Netscape was better than IE. But the fact is IE eventually outperformed Netscape even technically.

A lot of people who watched the whole thing on LKML consider the decision of merging CFS was unfair, but few really worried that we'd have a worse scheduler in the long run. Get your Cause and Consequence right.

What you describe is called...

[AlXtreme]

Minix!

Re:What you describe is called...

[Doc Ruby]

Almost. Minix includes a memory manager in the microkernel, which a nanokernel would treat as just another driver API. But it's close enough.

I see there's a Minix 3.0. Is there any possibility of stripping Linux 2.6.x into processes that could call the Minix 3.0 kernel? Is anyone working on that way of making "Linux apps run on Minix"?

Jitter is important

[dybdahl]

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.

Re:Jitter is important

[Anonymous Coward]

This reminds me of driving in traffic. Going in unpredictable stop and go traffic on the freeway is infuriating, and drives me nuts. Where as going on the local roads, and coming at a complete stop at lights feels faster because the stops are more predictable, even though the actual trip time can be the same or perhaps even slower than the stop and go freeway route.

You've got it backwards, then

[Anonymous Coward]

For me, the situation is reversed. If I have a free computer (and I usually do), Windows goes on it. Linux sits on my server and my laptop. If I want to game I use Windows, but for regular stuff like web, music, and movies I use Linux.

Also, Wine is *really* good right now, seriously. I'm running slightly older games like Half-life and Diablo II with full speed and no glitches whatsoever. I can use Steam, which has IE api calls, with NO dll's from MS Windows. I hear HL2 works with some tweaking, but if you don't feel like tweaking, that's why you keep a gaming machine around =P

Seriously, Linux is the best for everyday stuff and getting work done. Windows has it's place for niche applications. Why not treat them like that?

Isn't going to happen, period!

[qweqwe321]

Free and open source is a horrible model for any non-subscription based games. Think about a game like Oblivion, for example. If Bethesda had released that under the GPL, where would they make their money from? Unless you make money from subscriptions, like Second Life or World of Warcraft, FOSS games make no business sense.

Re:Isn't going to happen, period!

[Hatta]

Nethack seems to be doing just fine with it. The free and open source model has yielded a better game than proprietary developers could even imagine. Of course they side step the graphics issue by focusing on game play, but you can't argue with results.

Re:Isn't going to happen, period!

[psulonen]

I guess you're right if "not updated since 2003" counts as "doing fine." Don't get me wrong, Nethack was a great game around the turn of the millennium, but gaming has come a long way since then, with NH largely left where it was.

And no, I don't mean Oblivion.

Re:Isn't going to happen, period!

[aardvarkjoe]

Nethack is a great example of where open source game development shines. But you can't really say that it "rivals the commercial world" -- Nethack is simply not in the same market as the latest commercial 3D shooter or RPG. Commercial and FOSS games do not compete in any meaningful sense.

I have to say, though, that the summary is really silly. The kernel scheduler wouldn't make a list of the top hundred reasons why free software games don't compete with commercial software.

Re:Isn't going to happen, period!

[Hatta]

I don't think it rivals anything in the proprietary world. I think it outshines everything in the proprietary world.

Re:You won't get good games until you get marketsh

[CuteAlien]

The problem is that it's also not worth doing games for 0.5% of the 100% market. Well, 0.5% might be worth it (I don't know the exact numbers), but my point is that if you aim at such a small windows market that linux seems comparably big to it, any publishers interest in your game will drop seriously.

For Mac it's true to some extend as the Mac market is already larger. For example GarageGames (one of the companies doing mac-versions) once state that they sell more games on mac than on windows. But only about 10% on Linux.

Still you are partly right. On the linux market you can still stick out and that's good marketing. I think a lot of companies are missing that.

Re:You won't get good games until you get marketsh

[Kjella]

Sounds like an evil circle.

To get Market Share you need games.
To get Games you need Market Share.

Maybe, but it's not "To get Market Share you need games which rely on heavy 3D loads". There's plenty good games on Windows that could just as easily have been on Linux. I also don't think it's the best or easiest way to go, the OSS model is best at creating something that's continously improved. I don't want to play the same game over and over and get a "better experience" each time, not unless it's got really compelling multiplayer. Most games I play, I want them released, fairly stable and playable, play it, (play expansion, play user-generated content,) shelf it. I tire from every game, no matter how good within some months. OSS just isn't ready for that kind of "release 1.0" that I want.

Re:You won't get good games until you get marketsh

[Opportunist]

True on one hand, false on the other. Let's see how the PC became the "game machine" it is today. It wasn't that for a long, long time. Actually, some 20 years ago, the PC was anything but a platform suitable for gaming. There was the C64, there was the Amiga, all machines that were first of all cheaper and second heaps more suited for gaming than the PC, offering better graphics, better sound, better handling, more input devices and were pretty much geared for gaming. So why did the PC platform "win"?

The answer isn't simple, but I'd guess two factors play a key role here. First of all, it was perceived as a "business" computer, especially by parents buying a computer for their kids, rather than a "game" computer like the C64 or Amiga. More important, though, I think was the fact that it was heaps easier to upgrade the PC compared to the other hardware platforms that were pretty much set in stone. The A500 was the best computer for games when it hit the market, but it did not scale up. It was very hard to upgrade and you soon hit the limits. Also, Amiga made the big mistake and tried to keep the A500 as its main seller for longer than its lifetime allowed.

Now, how does this translate to software and OS? Well, Linux is modular, if anything. it allows speedy, easy and painless upgrading, compared to a Windows upgrade which pretty much means "throw out the old, bring in the new". It's also easier to keep "legacy software" running.

Maybe we shouldn't try to get the latest games onto Linux. Get the greatest games there first. I'm fairly sure that you'll attract a lot more people that way, and convince them of the platform. I doubt that a lot of Linux enthusiasts are there for the eye candy. They want sensible gameplay and good, solid entertainment rather than spectacular explosions with a storyline as deep as the average puddle forming in a rain. And such games are usually not really impossible to port without a staff of 200 dedicated artists and coders puzzling it together for over a year.

Re:You won't get good games until you get marketsh

[Opportunist]

Well, you could see it another way, too: If there's nobody but you creating games for Linux, you can essentially create a game that's been state of the art 3 years ago and still make a buck, something you can't do in the shark pool that Windows game developmnt is.

Re:Hmm

[Anonymous Coward]

I'm looking forward to the Knows-About-IO Scheduler (KAIOS). There's no plans for it yet, but I'm sure one of these decades they'll get around to it.

Re:Um

[Tim Browse]

Ya think?

Of course, because as we all know, it is only possible to write FOSS for Linux, and not for any other OS. Like, say, Windows, for instance.

Re:Modular Kernel GREAT QUESTION

[CuteAlien]

No he did not say that. He will no longer develop it, but he did _not_ quit because his scheduler was not chosen. I don't even know why so many people think so, maybe because it would be the way they would act?

CFS's impact is.. none!

[NekoXP]

Yeah they are too busy bitching about the difference between CFS and SD.

And then the news post here, says "Linux cannot suffer any setbacks in gaming". I think you'll find that compared to the original scheduler, CFS pretty much rocks for gaming. As much or less than SD, who the fuck cares?

It's better than the original scheduler, so where's the setback?

If it's not as good as SD, oh well, cry me a river. I don't agree with Linus' "there is no maintainer" idea, but more the concept that CFS removes more lines from the kernel than it replaces, and does a better job, whereas SD adds complexity for roughly the same effect. What could be a perfectly good technical reason in previous LKML posts got turned into politiking.

Difference between SD and CFS.. fractions of a frame per second. WOW. That really means Linus made the wrong decision! The impact on games, where 1/500th of a second really MAKES A DIFFERENCE is too high! Put the old scheduler back you fucking crazy-ass Finn!!

Let me say it again: Ingo sucks.

[ZeekWatson]

Lets not forget the intellectual theft perpetrated by Ingo Molnar. No matter how things turn out the guy is a liar, a thief, and a cheat. He sucks.

Ingo fought long and hard for the status quo. Complaints against the current O(1) scheduler (author: Ingo) were met with flames and ignorance. Con spent a year developing a new scheduler and proving that it was better than the scheduler that Ingo wrote. Ingo spent the entire year ignoring and denying Con's scheduler, but one day he saw the light and wrote his own knockoff in "62 hours" and gets it merged the next week. This is bullshit.

The end result is that Con has been driven from Kernel development by asses like Ingo. Whether CFS is better than SD is irrelevant. What has happened is the guy who spawned the entire process of getting an improved scheduler in the kernel and spent a year overseeing and improving it has his concept stolen by Ingo. Ingo did not want a new scheduler, he wanted his name to be on the current scheduler. When he saw that disappearing he had to take drastic action and he "authored" a new, improved scheduler. All for his own glory.

Ingo sucks.

Re:You won't get good games until you get marketsh

[RAMMS EIN]

``The trouble wasn't the OS. The games ran great. The trouble was that no one (but me, I guess) bought them.''

Now there's an interesting train of thought. Maybe the problem isn't that the Dammed Game Companies hate Linux and don't want to develop for it.

Maybe the problem is that the Dammed Linux Users hate paying and thus won't make game developers that target Linux rich.

Re:Games.. only thing keeping me from linux full-t

[CuteAlien]

Gaming is the main reason why people buy new computers at home. But I believe that gaming support on linux will improve soon. The reason I believe that is that in the last years the independend gaming scene was growing very fast and we care a lot more about linux than the big companies. Just check companies like Chronic Logic, GarageGames, Wolfire Software which all release linux version. And I'm far from naming them all. I did only recently join this scene, but I found out that for a small company it's actually rather easy to release Linux+Windows versions. There's not much of a technical challenge if you are careful when choosing your libraries. Maybe it's even a little easier because we can develop on Linux which has some advantages ;-)

Obstacles to commercial gaming on Linux.

[Runesabre]

The real obstacles with developing a commercial game on Linux isn't the performance or technicalities of developing the game like it was years ago; it's distribution and support.

Linux has plenty of horsepower and driver support these days to run even the most demanding 3D games and the development platform is consistent enough with Windows to make porting issues or cross-platform development a manageable, almost transparent task.

The big obstacle is distributing and supporting a game for Linux. For a third party developer such as a commercial game developer, packaging and releasing a game for Windows is a relatively easy, standardized task. A commercial developer knows that once they develop the game for Windows it's going to work as expected on the greater majority of consumer Windows machines in existence; even those running older versions of Windows and most likely will run on future versions of Windows. The commercial game developer generally does not have to worry about new hardware coming not working because of lack of drivers or new releases of the Windows OS coming out every 6 months that causes their product to stop functioning and needing fixed constantly. The commercial game developer doesn't have to be concerned with what other Windows developers are doing and whether changes going on in another area of the OS or applications being developed are going to effect their game development. Furthermore, the commercial game developer doesn't really have to spend extra effort dealing with multiple versions of Windows; for the most part Windows is Windows.

Contrast this with Linux, where there are literally dozens of recognizable distributions, none of which have an appreciable majority marketshare and many of which change dramatically every few months. Trying to maintain a game and keep it working from one version to the next of a single distribution is a sizeable task; trying to do that for dozens of distributions becomes prohibitive which is what a commercial game developer would have to do if they truly intended to support their game properly. And after all this effort, what would the effective sales increase of their game really be? The economics of properly distributing and supporting a game just isn't worth it.

If Linux really wants to be a practical target for commercial game development, it needs to bolster itself in the areas of distribution, support and platform compatibility stability. This will in turn not only make it more feasible for commercial game developers to consider targeting Linux as a valuable platform but improving these same factors would apply to all application developers and increase marketshare and commercial viability of Linux. If that is the desired effect, of course.

Re:Obstacles to commercial gaming on Linux.

[DVisions]

I remember when it was just as difficult to set-up a game on a windows system, trying to recall the interrupt request numbers for the sound & graphics card for your particular machine were such a pain. Or when that last floopy disk (disk #9) said finished, running that setup.exe command and getting a blank screen only then to comb the readme.txt for every piece of hardware to see if there was a work-around or if you just had to go without sound. As of right now it's as simple as letting the autorun install the game, laugh at the EULA, click yes, and wait a few minutes. For gaming to really take off on the x distro people need that same simplicity. There are several types of gamers out there and a big chunk of that demo are the ones who don't know the complete insides and out of their computer. Why do you think Alienware and the Dell gaming series continue to thrive? Yet, in my opinion, it's going to need another edge to get people to convert. As mentioned above somewhere linux will need a spectacular game, that's marketed properly, and **linux exclusive**. Right now the only games are simply ports that are bundled with the game or a launcher avialable for download; we need a seperate box on that Best Buy shelf. It needs hype and needs to deliver, of course this is as easy as dividing by zero - hence why it's never been done. While this is out there and not in a realm I know too much about but what if there was a specific linux distro for gamers, one that was heavily supported with 3D rendering, latest display drivers, and had it's own "DirectX" or something similiar that exceeds the current capabilities and will attract that hardcore gamer. We've all heard how the super-elite CS:S players fine tune their mouse - I've seen mice that have weights in them for more precise control - or adjusts the clipping plane to that perfect number to maximize their experience. Instead of in-game features make it in-system. Have a balance between a Gentoo and windows, have every single thing related to gamer customizable but have pre-defined optimized settings. And I need to stop daydreaming / rambling...

FOSS games?

[heffrey]

Oh please! You'll be talking about FOSS porn next!

Answer: Project Peach

[root_42]

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...

Re:Answer: Project Peach

[root_42]

D'oh! I am in Homer-Mode again. Of course I didn't mean PEACH, I meant the Apricot project: http://www.blender.org/blenderorg/blender-foundati on/2007-plans/apricot-open-game/

All those fruits... :-)

Re:Answer: Project Peach

[nuzak]

God help us if the production values are as bad as Orange.

"Emo! Emo! Emo! Emo! Emo! Emo! Emo! Emo! Emo! Emo!"

mod parent up

[Krishnoid]

No mod points for me today, but I notice this in day-to-day work all the time. I'm very interested in references to studies like that as I think it says something that could drastically improve the non-gaming Linux desktop experience.

Why scheduler debates might be so popular.

[BytePusher]

I think one of the reasons scheduler debates might be so popular, is that it's one just a few parts of an operating system that are easy to understand and also heavily emphasized in introductory computer science classes. Schedulers do matter in terms of user-experience, but in terms of overall performance they theoretically shouldn't make that much of a difference(except for the cost of switching tasks). I think that's what Linus is getting at when he says it's a small part. Previous schedulers worked fine, but this one allows a little bit "smoother" user experience.

That said, here is one example of how schedulers affect the lives of users:

I tend to play with the nice values of shared servers at my work place(It's nice to be the administrator.) when I'm compiling on the same machine as someone else who is running a simulation.. The compile time for my primary project(on an unburdened system) is around 20 minutes for a full recompile, while the simulation might take days to finish. If my compile process is equally nice as the simulation process it takes approximately double the time to complete, so I end up reading Slashdot for an extra 20 minutes and the simulation runs for about an extra 20 minutes. That's great on a day when I don't have deadlines to meet. When I give my compilation priority, I may see the compilation finish in 25 to 30 minutes and the simulation will run an extra 30-35 minutes as a result of my compilation. So I save 15 minutes on my compile while my coworker never notices the difference even if I do a full compile 10 times in one day. So the scheduler allows me (the interactive user) to work more productively.

Anyway, I don't know if that example was needed, but I hope it was helpful for someone.

That big a deal?

[WheelDweller]

Did Linus all the sudden lock out all other potential schedulers? Was the choice taken away? Root usually needs to install such games, and it's no big deal to change them at runtime, so relax, aye?

Other OS schedulers?

[mnemonic_]

Does anyone know what types of scheduling Windows XP and OS X use? It seems OS X grants highest CPU priority to the application process whose window is in focus, which seems to work very well. Would any type of communication between X.org and the linux kernel be possible to enhance process scheduling? Or is this already done? It seems natural that the (user) interface should talk to the kernel, even at a low level, to ensure overall OS responsiveness. After all, strictly speaking the user never really uses the operating system-- they only use the interface.

Re:Other OS schedulers?

[Anonymous Coward]

I think that could be emulated by the window manager renicing programs on the fly.

Priority Queueing and Hashing as an Option

[CodeBuster]

It might be nice if there was a mechanism whereby a priority queue was maintained with pointers into the red-black tree or other data structures used by the CFS module so that the superuser could designate that certain programs, identified via cryptographic hash, are special and should receive first consideration for scheduling while they are running. For example, during normal operations the priority queue would be empty and the CFS would handle scheduling in the usual fashion. However, once certain processes were loaded into the CFS *and* put into the priority queue (not every process goes into the priority queue, only the designated special ones), the CFS would know to check the priority queue when scheduling to see if there were any special processes running so that it could give those processes first crack at the processor and other resources in order of their priority (there could be multiple special processes running at the same time as well). In gaming, for example, it is usually the case that the user is focused entirely on the game and not on other processes running in the background so it would make sense for the game program's hash to be in the special priority queue so that it would receive top billing while it was running. It would also be possible to use this mechanism for other more usual processes (say on a server), but the CFS alone would probably be sufficient for most server type scenarios. The special scheduler add-on would really only be useful for special scenarios such as gaming, graphics rendering, and other long running and high demand processes. Perhaps something similar already exists, but I am not a Linux kernel programmer so maybe I just don't know about it...

Re:Priority Queueing and Hashing as an Option

[Lehk228]

you don't schedule rendering or other big tasks high, you schedule them low or idle. my roommate was running a major encoding task ast the same time i was with similar hardware, he set maximum priority (not real time thank god) i set mine minimum, i took about 15 seconds longer and had a perfectly usable machine aside from occasional slow downs with file i/o i couldn't play UT2k3, but web browsing, email, and even music was unaffected (after i cranked the file buffer in foobar to 5 megs so it would load nearly the whole song into memory rather than needing the hard drive often)

Re:You won't get good games until you get marketsh

[Anonymous Coward]

The limit to games on Linux is market share. Its not (much) easier to develop a good 3D game for linux as it is Windows,

Stupid assumption. If that were the case then we would all be running Amigas because DOS/Windows sucked for games.

Pehaps there was another compelling reason that DOS/Windows won? Think Price (Cheap).

Enjoy,

Re:You won't get good games until you get marketsh

[SwedishPenguin]

The limit to games on Linux is market share. Its not (much) easier to develop a good 3D game for linux as it is Windows, so why code for 2% of the market when you can code for 92% of the market?
Why code for 92% of the market when you can code for 100% of the market?

Strange viewpoint

[huckamania]

Games maybe cpu hogs, but the person playing the game probably thinks that whatever is causing the lag is the pig. I think that is the whole point.

The computer should spend cycles on the things the user is interested in, it should not be optimized primarily for the big service companies. The linux camp in 2007 just seems like some alternate dinosaur-computing reality: IBM, Sun, Novell, Oracle. I don't think of free or open when I see any of those names and I'm sure that none of those companies want to take computing in the direction I favor.

In the computing world, the enemy of your enemy is not your friend.

Re:Strange viewpoint

[abradsn]

So you are all for open source, just as long as it is closed to the big companies helping it most.

Re:You won't get good games until you get marketsh

[Zironic]

If you look at the most popular games today you'll notice at least a couple of them are heavily dependent on user created content and are continuously improved.

Half Life(1+2) and Warcraft 3 are great examples of this.

Games like this sounds very suitable for the OSS kind of model. If an OSS team could create a game engine with a map editor as powerful and easy to use as the one that comes with Warcraft 3 I think they could make a very competitive game even if the graphics is way below par. Just look how Warcraft 3 is dominating CC 3 that is allot newer with massively better graphics.

Or if they could write an FPS with the level of graphics of Half Life 1 would be enough if it allowed the community to easily create mods that might compete with Counter-Strike and Team Fortress.

http://www.xfire.com/cms/stats/

The OSS community has the ability to create competitive games if they wanted too since truly great games aren't about resource intensive graphics but about great preferably moddable game play. It wouldn't surprise me if there are already games like that out there that I'll never hear off because of the difficulty of marketing a game without a marketing budget.

Re:You won't get good games until you get marketsh

[Zironic]

The interesting thing is that a lot of the greatest games should already work on Linux. Since all of Blizzards games work on both OS X and Windows they should work on Linux too right? That makes Linux capable of playing all games I'll ever really want.

The problem is I think that there isn't any official support for Linux, if games companies would be willing to fully support atleast one Linux distribution I think a fair amount of people would be willing to take the last step. It would also help if more companies switched away from DirectX and started using the more compatible OpenGL.

Oblivion: Windows v. Linux

[omnirealm]

I play Oblivion using Wine on Gentoo. With a some .ini file tweakage (all spelled out at the uesp.net wiki), I actually get a better gaming experience under Linux than Windows. Surprisingly, this is mainly due to the fact that the Linux device drivers perform better than the Windows device drivers for my hardware.

Under Windows, the audio drivers for my built-in audio chipset (ICH8) on an Intel DG965 mainboard have trouble mixing multiple channels; the audio stutters when casting spells, for instance. Also, the gameplay is smoother under Linux than it is under Windows; I suspect this may be due to the IDE block device drivers for the DG965 board's controller, since the stuttering seems to coincide with disk access (DMA problems?). None of these hardware-related issues show up under Linux; all the audio plays without stuttering, and the gameplay is much smoother. This is all using the device drivers that ship in the mainline Linux kernel; no mucking with any drivers is necessary.

Of course, there are problems with Wine. Any version past 0.9.38 either does not work at all or crashes when you're running around in an outdoor part of the game. Trees sometimes render strangely; it seems that one of the vertices of some of the leaf objects is at the bottom-left corner of the screen, so sometimes streaks of tree leaves go across the screen. Water cannot render at more than a few frames a second, and refraction effects can make everything turn puke yellow/green. Most of these issues can be worked around by disabling the effects in the .ini file, but you have to go through the trouble of setting all that up, and you have to be willing to live without a few graphics effects.

Overall, there are problems with running Oblivion under Windows and under Linux+Wine, but I would rather live with the problems I am having under Linux rather than the problems I was having under Windows. Frankly, I am amazed that the Wine folks have managed to get something like oblivion running as well as it does.

Re:Oblivion: Windows v. Linux

[DaedalusHKX]

Don't feel left out, the ICH isn't the only chipset with issues. I have a K8Neo Platinum with the Nforce 4 SLI and Soundblaster 24bit, in windows it is a dream, in linux, once I finally got a good set of drivers for my Geforce, it did the riverdance around my windows setup and left it in the dust... I had a similar issue with the Radeon on this laptop. (Running ATI IXP chipset with a 200M) once I got it properly compiled, it was a screamer... other than in the graphics department, where the GPU was no less clunky than in windows. The drivers run far smoother with the linux IDE drivers for the IXP though. Back to the gaming rig... the problem is that the IDE drivers for the nforce4 in windows are not optimized, and you're stuck using emulated drivers off the driver disk, or the windows IDE drivers (which nvidia recommends during the downloaded software setup from their site). I've tried both, and they are both lame, at best. Linux seems to not have this issue, hence actually running this board at a speed I find, "reasonable" if not outright "good". (heh heh, and then there is hdparm :D

Just thought I'd let you know you're not alone in your experience with IDE drivers :)

(as an aside, I have a toy file server/backup that runs on a Celeron 300, last uptime was about 400 days with breaks only when power went down and the power backup ran out :) thing still copies files, large or small, locally or over network, far faster than a P600 with a better motherboard, more ram, and equally slow hard disks does in windows 2000/XP (I have lots of free time to test stuff out)).

Re:Games.. only thing keeping me from linux full-t

[Anonymous Coward]

"Linux is for those who hate Windows, BSD is for those who love Unix" becomes more true every day.

If game coders and hardware manufacturers got their heads out of their asses, compatibility wouldn't be an issue. They need to fix their shit, not the OS. Linux is Linux, people need to quit trying to turn it into a halfassed Windows clone. You want compatibility? Ask MicroSoft to release a DX9/10 library for Linux (or better yet, for BSD, as invariably Linux will "borrow" it much like OpenHAL anyway), or give permission to develop one outside of a clean room. Good fucking luck with that. Until then, please stay with Windows.

Re:You won't get good games until you get marketsh

[nweaver]

If cross platform requires more than 10% additional effort, that's why...

Re:You won't get good games until you get marketsh

[Jaeph]

"The limit to games on Linux is market share. Its not (much) easier to develop a good 3D game for linux as it is Windows, so why code for 2% of the market when you can code for 92% of the market?"

You can't make a business case in two sentences.

How big is that "2%"? How many sales could you expect? What is the cost of porting? Can you make the design to make the cost of porting lower?

I think that 2% is actually a decent number. I also think that making a game easy to port to both linux and mac will raise the market share significantly - in otherwords, if you can port to mac, it's probably an easy task to follow-up with linux.

So it's a question of a businessman spending a few days making an honest, mathematical assesment to see if there is a viable business plan. If there is, you do a quick prototype to see if there are any unforseen hitches. Assuming none, you and assuming your projections are reasonable, then you can make more money.

To be honest, I suspect most businessmen, rightfully or not, feel that linux is a hacker's/cracker's/pirate's platform, and don't feel there is a market there and thus don't follow-up with hard numbers.

-Jeff

Re:You won't get good games until you get marketsh

[Schraegstrichpunkt]

Loki started in 1998 and closed in 2002. Linux is a heck of a lot more popular now than it was back then. Popular enough? Perhaps not, but you can't use the 5-9 year old Loki experience as an argument for why Linux games can't work today.

Creative Commons is incompatible with GNU

[tepples]

Is it maybe just the lack of a good website where stuff like this could be indexed or isn't there a good enough standard license model to release something like that for free? I thought the Creatice Commons license would be quite suitabel for it. Actually, one of the biggest problems I've found with combining a Free program and a Free picture or sculpture into one work is that Creative Commons licenses are incompatible with GNU licenses (GPL, LGPL, GFDL) due to the credit removal obligation in all Creative Commons licenses.

Re:Creative Commons is incompatible with GNU

[Anonymous Coward]

one of the biggest problems I've found with combining a Free program and a Free picture or sculpture into one work

You mean, combining a CC-licensed work with a GFDL-licensed work, right? GPL and LGPL are really intended for programs, not content, and it's possible for game engines and their content to be released under different licenses; Doom and Quake have GPL-licensed engines, for example, but their commercial content is not released under a free license. If you release your game as separate content and engine packages, you can satisfy both the CC's requirement of removing credit from the content as well as the GPL's requirement to preserve credit on the engine. Right?

And does combining CC-licensed and GFDL-licensed works really come up much? My impression is that the vast majority of free content available is CC-licensed (or public domain), while the GFDL-licensed stuff is confined mainly to software manuals and Wikipedia.

Re:Creative Commons is incompatible with GNU

[tepples]

If you release your game as separate content and engine packages ...users won't download it because they have trouble downloading and unzipping one file, let alone two into the same folder. What sort of installer technology would you recommend using if, say, the game logic and the meshes/textures/maps must be provided separately?

you can satisfy both the CC's requirement of removing credit from the content as well as the GPL's requirement to preserve credit on the engine. Right? Can that be done if the target platform has only one drive and no internal storage?

Future of "Linux gaming"

[Half-pint HAL]

The commercial game developer doesn't have to be concerned with what other Windows developers are doing and whether changes going on in another area of the OS or applications being developed are going to effect their game development.

Ah... nail... head.

Distros, packages, rebuilds.

The only way to avoid these is a live CD. Build a custom build for your game; tweaked, trimmed and optimised. No dross, no unnecessary mailer daemons running in the background. Nononono. Just enough to run the game.

The best part of this? It doesn't care which OS you run normally. Windows boxes, Linux boxes, Macs... they're all the same beneath the lid now. 92% potential market share? Pshaw. This'd be more like 98%.

And that's not all -- my goodness: insert DVD then start the PC. Just like a console. How much more user friendly can you get?

HAL.

Re:Future of "Linux gaming"

[Anonymous Coward]

Are you serious? How much more friendly it can get than having to reboot your PC for every single game?
Like... for example compared to clicking the icon for a game on the desktop?

And it's certainly not the only way - as Windows is proving by still running basically every game from 10 years ago.

LSB is one way which helps to get GNU/Linux closer to the same target (thought it would help if it where integrated better in gcc - like with just another flag).

An even better way are most likely Webgames which can just be run in the browser (and yes - even complex games can be done that way).

Re:Future of "Linux gaming"

[Half-pint HAL]

And it's certainly not the only way - as Windows is proving by still running basically every game from 10 years ago.

Is it fair to assume that you haven't tried Vista yet? Even before that things weren't all that rosy, but now....

Let's just say there's more than one game in my library of classics that it won't talk to....

Limits of token non-Tivoized subsets of consoles?

[tepples]

Buy a Wii or PS3. They both run Linux

Since when does a Wii run Linux except in GameCube back-compat mode, which can see only half the Wii's RAM and can't see a USB keyboard or mouse? And since when does a PS3 have even 2D accelerated graphics hardware, so that moving windows around in X isn't jerky?

(By "since when" I ask for a year and month with a citation.)

Re:Games.. only thing keeping me from linux full-t

[linuxrocks123]

Apps don't drive the OS I use. Apps are expendable -- if you can't switch to another one at the drop of a hat, should doing so be required, you're doing something wrong.

I use Konqueror and sometimes Opera, but if I had to switch to Firefox it would be no biggy.

I'm using Thunderbird right now but thinking of switching to CONE.

I write my OWN PIM suite and financial apps, thankyouverymuch ... not trusting anyone else with those.

And I run Linux because it's technically the best operating system out there. But if Solaris has a few more home runs like ZFS I might switch that.

The OS is just a really big, really important app. Sacrificing it for lesser apps is a bad move.

Re: Ray Kurzweil/nanotech

[Night Goat]

Related to that in the literary realm, we've all been hearing about nanotech for years. I've working in sub-hundred-nanometer silicon for several years now, so I guess nanotech is getting a little passe'. I'm now reading Ray Kurzweil's "The Singularity Is Near" and I saw the term "picotech" for the first time.

Ray Kurzweil was on Coast to Coast AM a couple of weeks ago and talked about transhumanism, which apparently is the term for augmenting ourselves with computers and evolving ourselves to the next level of humanity. It was pretty neat, if you have the means of listening to repeats of that show I would suggest it. You might want to check out alt.binaries.sounds.radio.misc if your ISP has a decent retention level for Usenet. People tend to post Coast to Coast on that group as well as others.

What Linux needs.

[aliquis]

Ok, you are right that the scheduler might not be the most important part. Heck, I can't even understand why Linux can't ship with many different ones and let you choose when you build the kernel or with some system utilitity. Solaris offers a range of different schedulers.

Anyway, what Linux needs is GAMES, not functionality. The best way to help with the situation would probably be to write and release some quite simple games, maybe downloadable for free but with monthly fees to make more people pick them up and then get stuck ;)

If you're someone who will run Linux to play games you are probably smart enough to choose Nvidia anyway, but what does good 3D drivers help when there are no games to play?

Re:You won't get good games until you get marketsh

[petermgreen]

Most major games are written using pre-made engines like Unreal, which typically are cross-platform.
iirc epic at least charge a large ammount of money for each extra platform you want.

What about "nice?"

[level_headed_midwest]

Of course a fair scheduler will cause a single process to yield its CPU time- that's the point. It tries to spread the system resources out among as many similarly-niced processes as possible. Now if you want your game to run better than something else, why not renice the game -1 or renice the other stuff +1? I do this all the time to be able to run extremely compute-intensive processes in the background on my system and it makes them pretty much invisible to me (as long as they don't eat up all the RAM or do a lot of HDD I/O, of course.)

Absolute Priorities

[bobbuck]

Is there an option or a patch for Linux that runs the highest priority tasks first and then the lowest ones? i.e. task PuttingOutFires gets all the cpu even if MakingDinner and TakingOutTrash want time?

Well...

[obeythefist]

The thing about Linux is, why doesn't someone just make a pro-gamer distro? It's open source and GPL, so there is no reason why this can't be done.

Optimise everything for 3D acceleration etc. Bundle a bunch of open source games for the heck of it.

Or is there already such a thing? If so, what is it?

Re:Well...

[MrCopilot]

SuperGamerLiveDVD http://librenix.com/?inode=10887

live.linuX-gamers.net is a Linux live-dvd distribution: "boot 'n play" http://live.linux-gamers.net/

One of My Favorites, AdvanceCD is a bootable live CD, DVD and USB disk of a minimal Linux distribution containing the AdvanceMAME emulator.

You can boot it in any PC and play the contained games without any installation. The default distribution contains the arcade games Gridlee, Poly Play and Robby Roto and it uses only 20 Mbyte leaving the whole disk for your roms. http://advancemame.sourceforge.net/cd-readme.html

Games Knoppix
Review http://www.linux.com/articles/113906
Download http://www.games-knoppix.org/

http://gamer-linux.pappapc.com/

and on and on and on. You have heard of Google, yeah?

Re:Well...

[obeythefist]

Of course I have... but now all the other slashdot readers have also been reminded of these distros, hence me asking the question in /. instead of just wandering off to google.

Thanks for the info!

Re:Mods seem kind of *cranky* today

[tezbobobo]

That's some funny shit. My line of thought started out the same but --- 'hit someone over the head with it?! Lucky you're on slashdot else your GF would be pissed!

alternative solution

[CAIMLAS]

Here's an idea: why doesn't someone in the know create a 'game development' library base which could be dropped somewhere in /usr (or /opt or whatever's standard today) and be used as a stable-as-debian, cross-linux library base for games. Include all the standard things like SD, and optionally have them built to local base libraries - or whatever else is needed, I'm not really up on specific gaming libraries. But, at the least, it'd create a stable environment which game developers (and proprietary application developers, for that matter) could develop towards in the same fashion that they do for Windows.

Another idea, or possibility: while I'm not 100% sure it's possible or preferable, why not use a 'scheduler scheduler' to allow for active switching between scheduler profiles in a manner similar to how ACPI and APM work? I'm not going to want the same behavior while doing 'office' work as I would while watching a movie or gaming. It'd not make much sense on a server, I don't think, but on a workstation the ability to switch between task-oriented micro-schedulers seems like a pretty good idea, even if there's a several-percentage point processor performance hit. I imagine the loss would be made up in more task-appropriate performance if the user could be allowed to customize it: use x scheduler when x1 and x2 binaries are running, and y when y1 and y2 are running...

Re:Games.. only thing keeping me from linux full-t

[shutdown -p now]

OS is just a really big, really important app. Sacrificing it for lesser apps is a bad move.

Big, yes. But important? The sole purpose of an OS is to run other apps. The apps which actually let you do your job (or entertain yourself). OS by itself serves no purpose whatsoever. And therefore, when you say...

Apps don't drive the OS I use. Apps are expendable -- if you can't switch to another one at the drop of a hat, should doing so be required, you're doing something wrong.

... you get it precisely wrong. Apps are not expendable. If they have a certain features that no other applications have, and those features either make things previously impossible possible, or cut down the time needed to do something, then those features are what you want, and you don't care what OS runs under the hood. The OS, on the contrary, is quite expendable. After all, it's only there so that you can work with your apps.

And I run Linux because it's technically the best operating system out there.

Even if you restrict to Unix-likes, this is not true. There are only two reasons to run Linux: either because you are an FSF idealist, or because you like the better hardware and application support over BSD, Solaris, and the rest of the bunch. Both are good reasons in and of itself, but the latter one is even more applicable to Windows and Mac OS.

And, anyway, why should you as an end user bother about your OS being "best technically"? For example, does it really matter to you what algorithm the scheduler uses, as long as the end result - the picture on the screen - looks right (for your definition of "right")?

Re:Games.. only thing keeping me from linux full-t

[linuxrocks123]

> Apps are not expendable. If they have a certain features that no other applications have, and those features either make things previously impossible possible, or cut down the time needed to do something, then those features are what you want, and you don't care what OS runs under the hood.

That's a good point. But, in general, if a feature is truly useful it'll be quickly (for proprietary) or very quickly (for OSS) implemented by the other apps in the same field. If it's not, you need to ask yourself whether this feature is truly necessary, or if you're going about the problem wrong, before concluding no apps that meet your needs exist.

For example, if the feature is something like, "automatically uploads data to an FTP server when IU close it down", perhaps what you really want is to export the data to a file and then upload to the web site with a shell script and command-line. This is a cooked example; please don't argue with me on it in particular. My point is that apps shouldn't all try to do everything because the result may be obscure bugs in all apps. If a feature is only implemented by a few apps, it may be because the other developers realize that this feature doesn't belong in the problem domain.

On the other hand, if the feature is something like, "can read the undocumented binary file format of proprietary product X", then your current system is rotten on the inside. Your data should always be in standard formats readable by many apps, and if it isn't, you need to change that as soon as possible rather than continuing to be locked in to a single vendor.

As far as Linux not technically being the best OS out there, I guess we'll just agree to disagree on that one. The hardware support is nice (and actually superior to Windows and OS X), that's true, but I don't see any advantage in application support, really ... most apps that run on Linux also run on the BSDs and Solaris; porting between Unixes is easy. The main reason I currently find Linux technically superior is because of its excellent filesystem support. The FUSE project is truly supurb, and Linux's VFS layer also allows it to support a wide variety of filesystems in-kernel. It is true that ZFS is native to Solaris, though, and I'm watching closely how Linux responds to it.

Ask XBox owners

[Anonymous Coward]

They don't "click on an icon" to start a game. They seem to get away with it fine.

And as for boot times, this is mostly a solved problem as long as you have a proper BIOS.

Re:Games.. only thing keeping me from linux full-t

[Anonymous Coward]

(or better yet, for BSD, as invariably Linux will "borrow" it much like OpenHAL anyway)

Shut the fuck up. This "borrowing" is exactly what the BSD licence was designed to allow. If you don't like it, go shoot yourself in the face.

FOSS "games"

[Anonymous Coward]

FOSS games? Come on... It's like saying Christian games, do you see a future for Christian games?

Serious Sam

[J-1000]

I disagree. Responsiveness is important, but I've never encountered a situation where the frame rate was good and the machine couldn't read my keyboard clicks fast enough.

I've always had a bit of unwelcome latency in my controls for Serious Sam (the original). The framerate is great; it's the input that's slow.

Re:Seems like Linux / FOSS should be focusing on..

[Anonymous Coward]

Seems like many Linux people in the desktop space are high school and college kids.

Isn't that the age group most likely to buy games? (A large part of the problem is that those high school and college kids who use Linux are often enthusiasts, who have more than one PC, including one running Windows for games if that interests them at all.)

nice?

[jbo5112]

I didn't see any mention of using nice to adjust the priority. It would make a big difference to set the nice level of X11 and the game to -20, explicitly telling your scheduler that your game is important, unless of course, you think it's important to have your email server responsive while playing Q3.

Duh, its linux.

[Anonymous Coward]

"just hacking shit until it kinda works ok"

Uh, that's called "linux". The entire kernel is like that, because Linus thinks that's the best way to do things. Remember him saying how much BSDs suck because they take their time and do things right instead of just good enough?

Re:Duh, its linux.

[try_anything]

"Just hacking shit until it kinda works okay" is one way of seeing the initial phases of development, when you're trying to understand all the factors in play.

If you take an analytical approach from the start, you're going to start with some incorrect assumptions. Just one slightly incorrect assumption can result in a badly broken solution. Then you correct that assumption and start your calculations all over again. This is really wasteful and frustrating and usually results in the analytical guy giving up, throwing up his hands, and declaring that he "did it right," so the problems must be elsewhere.

Programming starts with research, and one form of that is "just hacking shit until it kinda works ok." Then you might have a sound basis for a formal design process, mathematical modeling, or whatever "doing it right" means to you.

Unfortunately, you rarely find one person who works well both ways. (I like to think I can, but I might be fooling myself. I program for a living, and it's not like they let you keep going after it "kinda works okay.") You're far better off with a guy hacking randomly without formal calculations than with a guy who thinks he can "do things right" without any random hacking.

What about "Priority inversion"

[krischik]

That is what I thought until I heared of Priority-Inversion. And indeed Priority-Inversion is the main problem I currently have with my backup processes.

Martin

[1] http://en.wikipedia.org/wiki/Priority_inversion

Priority inheritance

[krischik]

That's not enough. Read me other posting: http://linux.slashdot.org/comments.pl?sid=258139&c id=20097943 and be shure to follow the Wikipedia link as well. It was a real eye opener for me and made me rethink everything I knew about priorities.

So what you want is not Absolute Priorities but Priority Inheritance [1]. Otherwise TakingOutTrash might block the the very same CrossRoad object which PuttingOutFires desperately needs and in the meanwhile all the CPU goes to MakingDinner as MakingDinner has a higher priority then TakingOutTrash.

Martin

[1] http://en.wikipedia.org/wiki/Priority_inheritance

Nice won't help!

[krischik]

Nice was mentioned here: http://linux.slashdot.org/comments.pl?sid=258139&c id=20065199 and my answer on why nice won't help is here http://linux.slashdot.org/comments.pl?sid=258139&c id=20065199 and here http://linux.slashdot.org/comments.pl?sid=258139&c id=20097997.

Martin

Linus on microkernels

[EmbeddedJanitor]

We've all heard Linus' view on microkernels being computer science masturbation. Just because he explains it in terms that are familiar to most geeks does not make his argument right.

Many high performance OSs (including OSX, QNX etc) are based on microkernels. Many of these have been happily doing work on CPUs as low as 286s since the 80s.

It is also interesting to see how the various OSs change. Linux has grown more micro-kernel-like features (user space drivers and user space file systems). Windows CE (a microkernel OS) has added monolythic kernel features such as in-kernel drivers and in-kernel file systems.

Basically we're seeing that there is no "one true path" and system integrators need different features for different systems.

Re:You won't get good games until you get marketsh

[pkphilip]

I agree completely. Linux needs to grow in market share before it can be taken seriously by anyone, including game publishers.

For that to happen, the problems that keep Linux from gaining marketshare must be addressed. I am speaking about issues such as the difficultly in loading binary device drivers. The stock Linux kernel does include a lot of drivers, but there must really be a mechanism for loading drivers into the Linux machine even in binary form. Aand also an architecture for checking for automatic driver updates and downloading them off a driver repository.

If managing the devices on Linux as simple or simpler than on Windows, we will see a lot more people migrating to Linux from Windows.

It is pointless to say that device manufacturers must release code for their drivers, because that does not take into account the fact that there aren't enough Linux users for the device manufacturers to want to follow our dictates. If Linux gains about 30% market share, then it will be possible to get device manufacturers to release code for their drivers, but as long as Linux remains in the fringes, Linux users don't really have the type of clout it requires to demand things from hardware manufacturers.