[SDL] very precise control of display timing

David Olofson david.olofson at reologica.se
Fri Aug 24 09:06:01 PDT 2001

On Friday 24 August 2001 10:38, Pallier Christophe wrote:
> Hello,
> Many thanks to David Olofson for the detailed answer and the links
> provided!
> If I may add one question: From my readings about the TSC, I understood
> it was counting cycles.


> I intend to run my soft on laptops, some of
> which feature "mobile pentiums" that, if I understand correctly, can
> adjust their internal frequency depending on the current load of the
> processor...(I don't know if this is automatic or if this is under
> control of APM functions, but anyway, I cannot count on users using a
> kernel with APM disabled).

Then you also have some more sersious problems; you can't assume that 
users are going to use lowlatency patched kernels, RTLinux or even that 
they'll start you program as root so that it can activate SCHED_FIFO 

In short, even if it's possible to keep track of the refresh rate, 
there's no way you can guarantee that you program can control the display 
with anything like single frame accuracy.

> If this is correct, then one cannot count on the TSC to measure time...
> Am I wrong?

Some "clock throttling" solutions change the bus clock (and thus also the 
core clock which drives the TSC), but it seems like some don't. I don't 
know how the mobile intel CPUs do it, but I'm suspecting that you 
shouldn't trust the TSC on unknown machines in general.

> Second, I was aware of the RTC (I played with rtctest.c provided in the
> linux kernel source code), but I had not found any information about
> the latency.

It works like just about any other driver. It's driven by a hardware 
interrupt, which means that it wakes up sleeping threads immediately, 
unless there are higher priority threads, or the kernel is holding the 
wrong locks. (The latter is the real problem, and that's what 
Linux/lowlatency deals with.)

> I was afraid the scheduler may take a non-negligible
> amount of time before switching to the process blocked waiting on a
> "read /dev/rtc" (the "normal" beat of the scheduler is 100 Hz that is
> 10 msec).

No, that has nothing to do with it. The driver has it's own hardware 
timebase, so it can invoke the scheduler at any time, regardless of "HZ".

> A quick glance to one link given by David
> (http://www.uow.edu.au/~andrewm/linux/schedlat.html) suggests one can
> get the answer to this question.

Well, you can get the answer by studying the scheduler and RTC driver 
code. The latency measurement tools just let you measure the actual 
latencies caused by non-preemptable kernel code getting in the way.

> Finally, I am using sdl-1.2 where SDL_GetTicks() relies on
> gettimeofday() in the linux implementation. Is it still the same code
> in sdl-1.3? Are there any critical differences regarding timing between
> sdl-1.2 and sdl-1.3?

Don't know. Why would it change?

//David Olofson --- Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
|      Multimedia Application Integration Architecture      |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------------> http://www.linuxdj.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> david at linuxdj.com -'

More information about the SDL mailing list