Re: Important patch to fix select!

Jamie Lokier (lkd@tantalophile.demon.co.uk)
Thu, 8 Jul 1999 22:22:59 +0200


My credentials: I have written or modified several interactive games
inside and outside X, on several Unix variants.

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.

-- Jamie

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