As a answer to "you'll have to go through the non-RT X server", I
think they are relevant.
> The real question is do you really
> need RT for these tasks?
What I understand about RT, but I can easily be very wrong, is that it
isn't about answering immediatly to requests per se (the solution
there is buying more computing power and/or optimizing applications)
but to have a way to timely manage external signals with often very
short actions even if CPU-hogging tasks are running at the time. And
also not to be overwhelmed buy bunches of signals coming at the same
time (in case of propagating failures of systems for instance).
Now, what do games need, nowadays:
- 50 or 60 Hz screen update
- up to 200Hz music update (depending of the way the music is
generated and of the temporal precision of sound effects generation)
- <0.1s reactivity to player actions
- adaptativity to CPU busyness (frame dropping, etc...) to avoid a
general slowdown
- hability to have long-running processes to precompute things
For such things, RT is the best existing tool for now. The
high-latency (and low bandwhich) of X is what makes it so
unnacceptable for games, btw. Having quake only showing 5-10fps on a
quadriprocessor reality engine II kind of sucks.
I agree that games are very different from standard unixy applications
because they require a high level of interactivity, something at which
unix systems are generally bad at (they're slow or fast, but not
snappy). But then they only show what is going to be needed for
tomorrow applications, for instance on-the-fly compression and
decompression of video and audio data, voice recognition,
virtual/enhanced reality...
Buffering don't help when you need low-latency interactivity.
To sum up, add user-level, easy to use RT capabitilies to Linux and
they will be used much more than one RT-thread per system.
> Drivers which buffer data (like for the sound cards) can reduce the
> demand on the application. If the driver doesn't buffer enough, and
> you're recording sound, then an RT application may be justified
> (although a normal high priority process may suffice), since you don't
> want to loose data.
> Playing a video game, however, it might not matter if you loose a
> frame or two. The solution to frame dropping may be as simple as
> "don't run other things at the same time".
Provided that you have enough CPU, having to dedicate a system to each
RT application isn't acceptable.
OG.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/