> And one thing that showed up as a pain was the scheduling behaviour of
> select().
>
> For 3d games, precise frame timing doesn't seem to matter. You just
> don't notice. For 2d, if there's only a few things moving you really
> notice the difference between "smooth" and "not smooth". Ie. visual
> jitter. I'm going to describe what I had to do to get "smooth" under
> SunOS 4.
>
> Basically, to smoothly move an image across the screen at say 25Hz you
> have to do this:
>
> time = gettimeofday();
> while (1) {
> move_sprite_to_new_position();
> flush_X_commands();
> time = time 1/frame_rate;
> select(0,0,0,0, new_time - gettimeofday() - SCHEDULER_TICK);
> while (gettimeofday() < new_time) {
> /* Busy wait for av. 0.5 ticks, and _don't_ yield. */
> }
> }
>
> The ugly part is the busy wait. No matter how little is being
> displayed, we have to spent xx% CPU time busy waiting just so we can
> display at the right times.
>
> The xx% CPU is wasted even if we have other things to do like a sound
> mixer thread.
>
> The other ugly part is SCHEDULER_TICK. It varies from system to system.
> Actually SCHEDULER_TICK can be estimated by measuring actual scheduling
> times, filtering the estimate, and staying a bit short because jitter
> tends to enlarge rather than reduce the time.
>
> This is required if the machine is otherwise idle, or if it is busy.
>
> This is required even though the scheduling timer is ticking 3-4 times
> faster than the frame rate, and even with communicating with the X
> server asynchronously and so on. (As long as there's not a lot moving
> and it's in 2d).
>
> I haven't looked at those programs under Linux -- but from the
> discussion here it looks like Linux has a similar property: you have to
> select() and then do a busy wait. What a waste of CPU! We could be
> mixing sound in another thread during that time...
>
> Obviously _I'd_ like a select() that waits exactly the right amount of
> time, and then the process wakes up and competes for scheduling. If the
> system is idle or the process has high priority, it _should_ get
> scheduled as soon as the time expires.
>
> In other words, some acceptable version of the UTIME patch.
>
> My humble opinion. It's less relevant these days as with 3d full screen
> updates you just don't notice the jitter any more.
Basically what this type of application needs is regular repetitive scheduling.
A "wake me up at XXHz intervals" facility would make a lot of these types of
applications smooth and efficient. You would need some complexity to deal with a
heavily loaded machine. I think simply skipping some scheduling events on a
loaded machine would give the most tolerable result for most applications. In
this case it would help the application if it were informed how many scheduling
events have been missed since the last scheduling.
Steve
-
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/