I know this is way off topic (well, it’s for OpenGL applications, so it’s slightly motivated).
Background: I use RDTSC for timing on x86 CPUs, and realized that it will not work well on CPUs with on-line variable core frequencies (AMD PowerNOW!, Intel SpeedStep & Transmeta LongRun). PowerNOW! and LongRun are pretty well documented, but Intel SpeedStep seems to be very hush-hush (?).
My problem is that I need to detect if a CPU supports CPU frequency altering on-line, and I have not found a way to detect if SpeedStep is supported by a CPU.
Let’s assume for a moment, that the frequency will not vary too rapidly (ie no intermediate idle cycles or stuff like that … only when the user plugs the thing into the wall outlet). You can accumulate your RDTSC time until you hit an interval, that is long enough to be reasonably compared to the 18Hz system clock, say one second.
Then you crosscheck both timers. If the speed is largely different from before, adjust your RDTSC time scale.
I’m having a problem with SpeedStep and Windows XP right now. I’m trying to hit a specific frame rate, and when I’m ahead of the game, I Sleep() to give up the CPU, because WM_TIMER is too imprecise.
Well, what happens on a laptop is this:
laptop runs at 800 MHz
program uses most of the CPU
Windows raises CPU frequency to 1200 MHz
program detects that it has free cycles
program calls Sleep() each frame
Windows detects sleep, and lowers CPU frequency to 800 MHz
…
As I’m trying to use RDTSC as a stable time base (without the glitches imposed by GetTicks(), timeGetTime() or QueryPerformanceCounter(), and also without the 2-microsecond-per-call cost) this is very annoying. I tried turning it off in the BIOS, but Windows turns it right back on. Dell says there’s nothing they can do about it.
ARGH! Why can’t there be a measurement of time that is:
reasonably exact
cheap to read
won’t spuriously jump backwards or forwards compared to real time
I mean, why must this be SO HARD???
I guess this isn’t even vaguely OpenGL related. Sorry.
I have had similar ideas. It might work well enough, at least for Intel SpeedStep (based on power supply plugged in or not). I’ve heard the P4-M has “Enhanced” SpeedStep - what’s the difference? For PowerNOW! it would not work, I think (I don’t know the swithcing interval, but I think it can be several per second ?)
Originally posted by mcraighead: I really hope that a Sleep(0) does not cause a slowdown.
In what way does Sleep(0) differ from Sleep(1)? The minimum possible Sleep is 10-20 ms, so every Sleep that really is a Sleep will be the same as Sleep(10) at least. If Sleep(0) does not result in a Sleep (i.e. returns immediately), it has no effect anyway (why call it then?).
Originally posted by deepmind: There are docs on http://developer.intel.com/ giving the details on how to use CPUID to detect that.
I have searched the archives, but with no results (the only hint I got was that it might be possible to determine this by checking against known CPU family/stepping/vendor combinations, which is not really a nice solution). Do you have a name of the document(s), or perhaps you know which CPUID calls/bits are used?
Oh and you don’t have to worry about LongRun, since RDTSC has a fixed frequency on Crusoe processors anyway (Trasmetta are developper friendly )
How is that possible? Do they have a separate clock/counter for RDTSC? I was actually wondering how that would be implemented - if RDTSC is based on x86 “cycles/instructions” or core (VLIW) cycles.
Originally posted by marcus256: How is that possible? Do they have a separate clock/counter for RDTSC? I was actually wondering how that would be implemented - if RDTSC is based on x86 “cycles/instructions” or core (VLIW) cycles.
I don’t know the details, but when I was asking on clax how to deal with RDTSC on Crusoe processors, a Trasmetta guy assured me it has fixed frequency even with LongRun enabled.
btw, you should post your questions to clax, you’ll have more chances to get the info…
EDIT: “clax” is comp.lang.asm.x86 on Usenet.
Julien.
[This message has been edited by deepmind (edited 06-13-2002).]
btw, you should post your questions to clax, you’ll have more chances to get the info…
EDIT: “clax” is comp.lang.asm.x86 on Usenet.
I realize that this is not the best forum. Unfortunately I do not have access to a good News server. so thet is why I do not use Usenet more frequently.
jwatte,
You describe a situation where the CPU frequency is controled by the CPU load. This does not sound like Intel SpeedStep technology to me (AFAIK, Intel SpeedStep only acts on if the computer is running on battery or not). What system are you running on?
The original SpeedStep technology had the performance based on whether the computer was AC powered, but current Intel mobile CPUs and chipsets support “enhanced” SpeedStep. Under enhanced SpeedStep the CPU spends most of its time at the lower performance state and only jumps up to the higher performance state when it is maxed out.
But even if you disabled SpeedStep you may still not be able to rely on RDTSC in the way that you desire. On mobile Pentium II and Pentium III processors the timestamp counter stops during the ACPI C2 and C3 idle states. It also stops during C3 on mobile Pentium 4 processors. Mobile systems make extensive use of C2 and C3 when they are idle.
