View Single Post
Old 05-14-03, 08:29 AM   #2
Registered User
Join Date: Sep 2002
Posts: 2,262

This isn't a bug with the drivers, it's a side effect of the Linux kernel timer resolution. The kernel scheduler (at least, this is my understanding of it) runs once every 1/HZ seconds (HZ is 100 on Intel machines, and 1024 on certain others).

This means that there is a latency of 1/HZ seconds, or 10ms, possible if any thread (or process) gives up control.

This also means that the vertical retrace can't be synced to by waiting for an interrupt; the userspace code that runs in response to that interrupt might be very, very late.

So instead, the drivers busy-wait on the vertical retrace signal. When a retrace is in progress, they return (and glXSwapBuffers finishes).

The only way to change this is to change the kernel timer resolution. Or, change your threading package to be a preemptive one (AKA pthreads) rather than a cooperative one. There's no reason a high CPU utilization in one thread would stop others from running, especially if they're only doing I/O, unless you're using a userspace threading package that can only do cooperative multitasking.
Registered Linux User #219692
bwkaz is offline   Reply With Quote