That's right. The problem is jitter which is visually noticeable -- the
fixed delay is something we seem to ignore easily.
BTW in the source I forgot to mention that the select() delay can come
out negative -- then you don't call select() of course.
> Now it could be that if you try to go for 30Hz, the one-in-three times
> that you'd have 4 timer ticks instead of 3 looks really lowsy. But if
> you evenly divide into an integer number of timer ticks it should work
> about as good as your implementation. Of course, 70Hz is pushing the
> limit... You'd want a 14ms wakup call, but in reality get 0, 10 or
> twenty. That probably doesn't look too good.
Quite. Jitter.
That's why I'm not too fussed about whether an extra tick is added or
not in general -- the busy wait is necessary in either case to get rid
of jitter. I would like to see accurate schedule timing but that's a
different problem.
> Decoupling the kernel-HZ and the userland HZ will certainly help. I've
> posted about that in a different message. If done right, we should be
> able to increase kernel-HZ to any value the hardware can support....
Or decouple timed scheduling from HZ altogether.
> I find it odd that 3d games have less of a problem with this. Maybe
> the 3D graphics accellerator smoothens things out, because it is
> always running at max throughput....
I was referring to software-only rendering.
It seems to be a perceptual thing -- the whole screen changes, and
there's so much going on that you just don't notice the perceptual
jitter. Also there is jitter due to the limit on screen switching
times.
BTW 3d games get away with a much lower frame rate than 2d for that
"smooth" look too. Though if you're a fussy viewer you do need high
rates for both.
-- 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/