The future of realtime Linux in doubt

The timing for certain types of games is critical. The 'Mortal Kombat' style fighting games, for instance, can be extremely competitive.

One of the biggest problems faced by consoles is that while they are much faster then older systems they are also much slower in other ways. For your average RTS or whatever it's pretty irrelevant.. and for FPS games network latency is a much bigger problem that masks other lesser sources of latency, but it's still a issue that needs to be addressed.

The 'pipeline' from a button press on a USB device, through the kernel, through the display server, through to the application, and then back through the GPU and being rendered on the screen is a extremely long one.

Ideally response should be probably under 10ms or at least it should be very consistent if you can't get that.

I think people underestimate what it takes to actually have a human interface device. It's not easy and when things are latency sensitive the intense complexity of modern OS is a huge liability.

> PC hardware was the GPU drivers locking the bus for excessive periods (to improve draw performance).

Shit graphics drivers have always been a especially big problem on Linux, but once you get that tackled you still have to deal with the rest of the system.

> DSPs to the SoC, which seems to work fine...

And it adds money, development time, and unfixable bugs. It also reduces flexibility.

If you can do everything using software using generic off the shelf parts you have a huge advantage.

I wish that more game developers did care and use real time code techniques. The last game developer that seemed to care was John Carmack. The idtech 5 engine used for Rage does 60 fps. All the time. The textures may not be right yet but the game WILL run at full speed. I've seen the textures pop but I've never seen it jank like other games do.

On an unloaded system (like a console) real-time scheduling and such isn't needed, because if the CPU is doing only one thing and it is fast enough there isn't any need to prioritize things. But the *techniques* used in RT coding still apply. Don't let your RT threads block on IO not even memory paging. Use work queuing and lock-free algorithms instead of mutexes. Etc. Maybe the game AI falls behind the player but the UI should remain smooth and interactive under ALL conditions.

I do think it would be nice if game developers went that little extra way to use a real-time scheduling class and memory locking to guarantee good game play no matter what other applications start running or how much memory they use.