pouët.net

Since some demos are on linux, I assume some of you have tackled that problem.

What I want( for X-mas ) : a timer with a precision in microseconds

What I have: I currently use gettimeofday, problem is that the last 3 digits (left to right) of tv_usec are always 0. So precision is actually in milliseconds.
And apparently this function can be buggy.

I don't want to use 'rdtsc' because I have an SMP system (AMD64 X2 )

From this link,
http://www.guyrutenberg.com/2007/09/22/profiling-code-using-clock_gettime/

seems like clock_gettime is the way to go. But I would have never figured out you have to link with librt.a
I'll try that

I haven't enabled all the high performance timer stuff in my Kernel config, should I enable it? Maybe that's why gettimeofday is behaving badly.

So what do you use?

why do you need such high precision?
demo?

I'd like to have at least 1/10 000 th of a second.
I'm coding OpenGl stuff in wireframe, and I get close to 1000 fps.
So my delta time is very close to 1 millisecond.

duffman, does it runs smooth? :) why don't you just do the delta every Nth frames?

Yeah I can do that, or every xx millisecond. I do that for my updates( everything but render stuff ).
I like letting the render go as fast as it can and get an FPS count. I'm not using different threads.
But I also want to do some profiling, hence the need for something more accurate than millisec.

I always wonder why people want to render much more frames than the monitor can display.

what pmdata said.

CONFIG_NO_HZ

(which typically goes with config_high_res_timers of course..)
Drawing stuff at ridiculous framerates isn't good practice even when you're just profiling since it tends to cause a number of odd side effects but it doesn't follow that good timers are useless. For instance using 100Hz timer directly for motion will make your demo a little jerky despite it being more than your refresh rate.

Maybe he doensnt want to render more frames that can displayed but he wants to bench each frame so he can still detect a big framerate drop (say from 1 to 2 ms) when he adds one functionnality, so he can optimise; you'll say wtf thats still 500fps but that functionnality maybe will have the same impact once the engine runs at 30fps.
besides, what if someone uses a slower machine.
besides, one might want to precisely time code. linux sucks hard! :)
i dont see why high frame rates "cause a number of problems" if you code correctly but i might be wrong.

Check Wine's source for queryperformancecounter ;)

Or not, because your bottleneck will probably change when you switch from 600 FPS to 60.

Absolutely. Maybe, maybe not. Still it's useful to time things.
As a side note, DXSDK had an interesting article about timing and multicore, game timing code broken by rdtsc, queryperformancecounter and the like.

(while i'm at it, in an sdl program that displayed frame rate, i replaced my deltaTime with 1 ms when i found zero, seemed the cleanest hack. but i'm aware with a complex physic engine this might lead to things getting out of sync or something... i see no easy solution.)
1ms is not a that great a resolution.
besides, heres a great article about timing by gaffer (tinyPTC!)
http://gafferongames.wordpress.com/game-physics/fix-your-timestep/
(i think there are more on this on the site)
this is not a trivial problem at least for me :) )

Silly question, but do you have HPET turned on in your BIOS?

Uh, you posted the answer to your own question...

The page you posted links to here which links to this example.

Compiles and works here, links with -lrt nicely too.

-lrt
jsyk

Thanks for your input guys.

I know it's pointless to let the rendering go full throttle, but, like HeLLoWorld said, I use it to catch those smaller drops.
For example, I was drawing a quad full screen and I tried leaving the DEPTH_TEST, ALPHA_TEST, etc, enabled with a ALWAYS pass, instead of disabling them(that openGl invariance rule). I had a 100 frames drop. But anyway, this was just a test case, and my gfx card is an onboard geforce 6150se with shared memory and no stencil buffer.
So some of the performance hit I get might not occur on better hardware.

Back to the main topic. Yes that link I posted did the job. I enabled the High Performance in the Kernel, but not the NO_HZ. It's nice to have a more precise clock.

LiraNuna: I'm not sure, I'll check. I did enable the HPET option in the Kernel, but dmesg doesn't report anywhere that HPET is used instead of the old method. I don't really understand all that stuff. I'll have to read.

when I switched to ubuntu I was surprised that clock() from sys/time.h was bugged , with no correct resolution apparently. ( 1/50 sec would be enough for me, but it couldn't even do that on ubuntu.)

After having read some forums, it seems the "best" common answer for a microsecond timer is:
sys/time.h

struct timeval tv;
struct timezone tz;

gettimeofday( &tv,&tz);

unsigned long long microseconds = tv.tv_sec * 1000000L + tv.tv_usec;

It sucks ? sorry !
The worst case is if someone change the hour during your demo: timer broken. Better idea anyone ?

... so maybe a config could fix clock() like 216 wrote...

gettimeofday appears to be the only option that's available without assuming special kernels. However, keep in mind that gettimeofday eats quite some CPU time, it's nothing to be used in inner loops.

What I do is use TSC (via rdtsc) and tune this every 100ms using gettimeofday (as TSC speed may change due to CPU throttling). If a multi-core CPU is involved doing the rdtsc + tuning in a thread that's bound to a specific core should do the trick.