Back to General and Gameplay Programming

Anyone having issues with Dual Core CPUs and timers?

General and Gameplay Programming Programming

Started by MARS_999 August 14, 2006 08:26 PM

23 comments, last by e-u-l-o-g-y 17 years, 7 months ago

MARS_999

1,627

Author

August 15, 2006 03:52 AM

Quote:Original post by Evil Steve
LARGE_INTEGER is essentially just a wrapper around __int64, so swapping one for the other won't help at all. You should either install the patches or use SetThreadAffinityMask to force the timer thread onto one processor.

Personally, I use the SetThreadAffinityMask method, since I know that otherwise if I release an app using QPC(), someone will complain that it doesn't work and that it's "my fault" for not fixing it somehow.

Thanks for the reply Evil Steve, so how does your code look for SetThreadAffinityMask then if you don't mind me asking... Thanks

Evil Steve

2,021

August 15, 2006 04:02 AM

Quote:Original post by MARS_999
Thanks for the reply Evil Steve, so how does your code look for SetThreadAffinityMask then if you don't mind me asking... Thanks

Just in my main thread:
SetThreadAffinityMask(GetCurrentThread(), 0x01);

I think anyway, I don't have my code with me.

bit64

218

August 28, 2006 09:16 AM

Quote:Original post by hplus0603

However, the right solution is to get the patches from MS and AMD to work. I had no problems with that, and I don't know anyone who did, so it's clearly possible.

Actually, the right solution is to set the thread affinity. You cannot rely on your customers to be patched correctly.
Do not use the SetProcessAffinity unless you don't want your application taking advantage of the dualcore performance enhancements, just use SetThreadAffinityMask and make sure your counter runs on its own thread.

Don't be afraid to be yourself. Nobody else ever will be.

Jan Wassenberg

1,000

August 28, 2006 02:42 PM

Quote: just use SetThreadAffinityMask and make sure your counter runs on its own thread.

huh, that sounds not exactly lightweight. So does your get_time() API send a message to the timer thread and wait for an answer?

E8 17 00 42 CE DC D2 DC E4 EA C4 40 CA DA C2 D8 CC 40 CA D0 E8 40E0 CA CA 96 5B B0 16 50 D7 D4 02 B2 02 86 E2 CD 21 58 48 79 F2 C3

ApochPiQ

23,138

August 28, 2006 03:01 PM

That's not what he meant - you don't have a thread that runs your timer and nothing else; you just run your timer in the same thread that needs being timed.

A better way to say it is that every thread that checks timings needs to maintain its own timer variables internally, and set its own processor affinity mask. If you're willing to do a little work, you can even check for multiple processors, and set up the affinities so that your threads are more evenly distributed across the available CPUs.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

Conner McCloud

1,135

August 28, 2006 03:06 PM

Quote:Original post by bit64
Actually, the right solution is to set the thread affinity. You cannot rely on your customers to be patched correctly.

Sure you can, its done all the time. Pick any random game, and I'll bet they suggest updating your video card drivers if you experience problems.

CM

Jan Wassenberg

1,000

August 29, 2006 03:52 AM

Quote:you just run your timer in the same thread that needs being timed.
A better way to say it is that every thread that checks timings needs to maintain its own timer variables internally, and set its own processor affinity mask.

Timer state in TLS? Interesting.
Doesn't sound too safe, though - if 2 threads (UI and main engine) have some timestamp they need to agree on, you are back to square 1.

Quote:If you're willing to do a little work, you can even check for multiple processors, and set up the affinities so that your threads are more evenly distributed across the available CPUs.

hoo boy, sounds dangerous. You need to take HT into account, else your game will run like a dog when you farm out worker threads to every single virtual 'CPU'. You have therefore committed yourself to releasing patches for all future CPU changes (e.g. when AMD adds something like HT).

Also, if user is burning a CD while playing your game (now quite viable with dual core), you potentially mess that up for him. Probably better to let OS take care of scheduling!

E8 17 00 42 CE DC D2 DC E4 EA C4 40 CA DA C2 D8 CC 40 CA D0 E8 40E0 CA CA 96 5B B0 16 50 D7 D4 02 B2 02 86 E2 CD 21 58 48 79 F2 C3

bit64

218

August 30, 2006 06:10 PM

Perhaps I should be more clear. When I say that you should make sure that your timer calls are on their own thread, I mean that the differences between SetProcessAffinity and SetThreadAffinity are only remarkable if your application has more than one thread! Simple as that.

Calling SetProcessAffinity on a multithreaded application will kill any advantage you would have of running on a dual core CPU.

Don't be afraid to be yourself. Nobody else ever will be.

tompp

126

August 30, 2006 06:19 PM

Slight problem that on Windows XP x64 uses the server kernel, QueryPeformance* functions will use the time stamp counters (rdtsc). (At least it did at the time when it was in beta). Also, the HPT timers are relatively expensive to use (not that you have too much options). There is an excellent article on gameDev's (see resources) on timing in windows.

Beware of the Mighty Hamster!

MARS_999

1,627

Author

August 30, 2006 09:18 PM

I am thinking that the use for HP timers would be needed for acurate physics?

Anyone having issues with Dual Core CPUs and timers?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Anyone having issues with Dual Core CPUs and timers?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines