Windows timer

This might be worth a read. Beware that QPC() has a few issues with it.

Personally, I use timeGetTime() and measure how many frames get rendered in Xms rather than how long 1 frame takes.

It sounds like a definetly better idea. However, I must say that so far I've been rather happy with QPC, when coupled with an affinity mask? Maybe I have been just lucky? That would be terrible.

Quote:

Original post by Evil Steve This might be worth a read. Beware that QPC() has a few issues with it. Personally, I use timeGetTime() and measure how many frames get rendered in Xms rather than how long 1 frame takes.

I took a look at that article and it was very interesting (it seems that nothing is really a good idea). I am looking to create a timer that can do more then just see how many frames got rendered in a certain time, I also would like to see the amount of time passed (in seconds, milliseconds, or anything) for profiling.

Quote:

Original post by Krohm It sounds like a definetly better idea. However, I must say that so far I've been rather happy with QPC, when coupled with an affinity mask? Maybe I have been just lucky? That would be terrible.

Could you post an implementation of how you use it, or where you learned how to use it? I do not see what I am doing wrong

Quote:

Original post by simotix Could you post an implementation of how you use it, or where you learned how to use it? I do not see what I am doing wrong

Sorry simotix, I wasn't referring to what you're doing but rather to what I am doing.
The only thing that's different to me is that I work on delta times and avoid FP math when possible.

Quote:

m_fFractionOfSecondPassed = (m_liPerfStart.QuadPart - m_liPerfLast.QuadPart) / (float)m_liPerfFreq.QuadPart;

Cast to double, not float. Floats have the potential to incur considerable precision loss, as the integer values you're dividing can be very large. Plus their size is hardware dependant so the accuracy problems are likely to pop up on other systems even if it works fine on yours.

If you cast to double and you're using D3D remember that you'll need D3DCREATE_FPU_PRESERVE in your CreateDevice otherwise you'll just make things worse.

Quote:

Original post by taz0010 Quote: m_fFractionOfSecondPassed = (m_liPerfStart.QuadPart - m_liPerfLast.QuadPart) / (float)m_liPerfFreq.QuadPart; Cast to double, not float. Floats have the potential to incur considerable precision loss, as the integer values you're dividing can be very large. Plus their size is hardware dependant so the accuracy problems are likely to pop up on other systems even if it works fine on yours.

Either way, I am looking of seeing if that way of determining the fraction of a second passed is correct

Quote:

If you cast to double and you're using D3D remember that you'll need D3DCREATE_FPU_PRESERVE in your CreateDevice otherwise you'll just make things worse.

There are some posts on various forums that claim the DirectX API changes the precision mode to single, affecting *all* calculations throughout your program. There is not mentioned in the documentation however. Under D3DCREATE_FPU_PRESERVE, it says:

Quote:

Set the precision for Direct3D floating-point calculations to the precision used by the calling thread. If you do not specify this flag, Direct3D defaults to single-precision round-to-nearest mode for two reasons: Double-precision mode will reduce Direct3D performance. Portions of Direct3D assume floating-point unit exceptions are masked; unmasking these exceptions may result in undefined behavior.

Which implies that the forced single precision is only in affect during DirectX API calls.

To test this, I had my program load in two double precision values from a text file, divide them and output the result. The program was displaying the correct double precision value, while using single precision datatypes resulted in the expected loss of precision.
I tried this both with and without SSE (which I'm told ignores the FP setting outright), and with the various floating point settings (strict/fast/precise).
My resulted showed no indication that the CPU precision flag had been affected.

So this may be an issue that doesn't affect the hardware I'm using, or maybe it's something Microsoft patched out? Not being able to rely on 64 bit precision is a pretty huge issue IMO.

Quote:

Either way, I am looking of seeing if that way of determining the fraction of a second passed is correct

Yes that's how it's done. There are more complicated implementations (running on own thread, setting CPU affinity) which are used to avoid bugs which are present on some hardware.

Quote:

I took a look at that article and it was very interesting (it seems that nothing is really a good idea).

hm, I wish that article contained a link to its newer version at http://wassenberg.dreamhosters.com/articles.html, because there are indeed safe solutions (either Windows 7, or a homemade HPET driver for XP, or requiring a CPU with invariant TSC, or affinitizing, but I don't like the latter).

Quote:

So this may be an issue that doesn't affect the hardware I'm using, or maybe it's something Microsoft patched out? Not being able to rely on 64 bit precision is a pretty huge issue IMO.

Yeah - they're probably not doing that many multiplies/divides in software anymore. Also, the P4 uarch added optimizations for FLDCW that might have made it feasible to switch precision upon entry/exit.

Quote:

I tried this both with and without SSE (which I'm told ignores the FP setting outright)

Correct - there is no precision control, but SSE's MXCSR does provide a rounding control.

Quote:

Original post by taz0010 Quote: If you cast to double and you're using D3D remember that you'll need D3DCREATE_FPU_PRESERVE in your CreateDevice otherwise you'll just make things worse. There are some posts on various forums that claim the DirectX API changes the precision mode to single, affecting *all* calculations throughout your program. There is not mentioned in the documentation however. Under D3DCREATE_FPU_PRESERVE, it says: Quote: Set the precision for Direct3D floating-point calculations to the precision used by the calling thread. If you do not specify this flag, Direct3D defaults to single-precision round-to-nearest mode for two reasons: Double-precision mode will reduce Direct3D performance. Portions of Direct3D assume floating-point unit exceptions are masked; unmasking these exceptions may result in undefined behavior. Which implies that the forced single precision is only in affect during DirectX API calls. To test this, I had my program load in two double precision values from a text file, divide them and output the result. The program was displaying the correct double precision value, while using single precision datatypes resulted in the expected loss of precision. I tried this both with and without SSE (which I'm told ignores the FP setting outright), and with the various floating point settings (strict/fast/precise). My resulted showed no indication that the CPU precision flag had been affected. So this may be an issue that doesn't affect the hardware I'm using, or maybe it's something Microsoft patched out? Not being able to rely on 64 bit precision is a pretty huge issue IMO.

So are you recommending that I do or do not use this?

Quote:

Original post by taz0010 Quote: Either way, I am looking of seeing if that way of determining the fraction of a second passed is correct Yes that's how it's done. There are more complicated implementations (running on own thread, setting CPU affinity) which are used to avoid bugs which are present on some hardware.

I am currently brushing up on my threading after taking a long break for it and I will run it in its own thread. I will probably respond to this thread in the future about this. I understand it running in its own thread, but why does CPU affinity matter?

Quote:

I understand it running in its own thread, but why does CPU affinity matter?

Each CPU core has it's own timer state whose values will inevitably drift apart. As part of the multitasking process, Windows will periodically switch the process over to a different core, and on some systems, this will result in the timer value of the new core being read instead of the old one. The timer fluctuation will result in choppy movement, and negative timestep values being generated. AMD released a software patch a while back, which (I think) periodically synchronises the timers on each core. I don't know if the problem affected Intel CPUs or not.

Anyway, setting the CPU affinity to one core only will ensure that the thread is only run on that core, which eliminates the issue entirely. But there can be a pretty big performance hit if the core you set affinity to is being used for something else. Having a thread just for the timer will reduce the impact.