-
Competitor rules
Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.
AMD Dual-Core Optimizer - is it nessessary?
- Thread starter saguy
- Start date
Are not the AMD Dual-Core Optimizer and the AMD CPU driver the same thing because I can only find the optimizer on the AMD site?
Associate
- Joined
- 19 Jun 2007
- Posts
- 1,498
i get some random error in some programs, and some games go weirdly if i dont install the dual core optimizer.
I been running Dual-Core Optimizer for a couple of months now and have had know problems, but when I first got my dual core I did not know about AMD Dual-Core Optimizer therefore I did not install it for about 3 weeks before I went to the AMD site and noticed the driver. but between running with and with out I can honestly say I did not notice any difference when I did install it I'm sure it has its purpose so its installed and forgotten about.
cheers
Dean
cheers
Dean
When i was running my opty 170 some games would play like they were in fast forward. GTA: san andreas was one of the worst for it. i had to change the affinity to just 1 core for it to play at the correct speed. maybe the Optimizer would have fixed this?
Permabanned
- Joined
- 19 Jun 2007
- Posts
- 10,717
- Location
- InURmama
It can go well or go wrong, you can only but try.
" How to install the AMD X2 drivers, hotfix, the correct way. "
http://www.xtremesystems.org/forums/showthread.php?t=81429
" How to install the AMD X2 drivers, hotfix, the correct way. "
http://www.xtremesystems.org/forums/showthread.php?t=81429
Great link, thanks
I had the same sorta problem in BF2, optimizer fixed it
This is a post I wrote a while back explaining how the DCO works and how and why it should make the system run better. Hope you find it useful 
-----
The Win32 API contains other APIs such as QueryPerformanceTimer and QueryPerformanceFrequency. Basically these are application based timing systems. Now games and rendering applications use these API calls to retrieve very accurate timing information, on which they base their frame rendering and physics engines.
Some games, however, bypass the Win32 API. Instead of using this software based timing, they use a hardware based timing by calling something known as the RDTSC x86 instruction.
Now each core on a multicore system has a RDTSC (Read Time Stamp Counter) which is a bit like a clock. So, for the sake of argument, let's take a single threaded game running on a dual core system. Now the API assigns the game to Core 0. So Core 0 is processing game information like this:
TSC @ 1000 - frame 1
TSC @ 1100 - frame 2
TSC @ 1200 - frame 3
TSC @ 1300 - frame 4
Because Core Affinity is not assigned, the API can switch the game thread from one core to the other. This could be for any number of reasons, but a lot of single threaded apps will behave like this. If you run a single threaded program, you'll often notice that instead of one core being at 100% and the other being at 0%, both will hover around 50%. This is the API moving the thread constantly between cores to even out the load.
The problem appears when the API switches the thread to the other core. At frame 4 in the above example, Core 0's RDTSC is at 1300. However, Core 1's RDTSC could well be anything. Let's say it's at 1100. When this happens, as you can see, the timing is completely messed up. From the game's point of view, time has gone backwards. Only 2 frames, admittedly, but this happens continuously and is what causes stuttering and other problems.
Now for the DCO. In short, it "listens" for timing related calls either to the Win32 API or the RDTSC x86 instruction. Then, it reroutes them to a core-independent timing system (the power management timer). Therefore the game (or whatever app) works correctly, even when the API is moving the thread between cores.
As a side note, the power management timer is what the /usepmtimer switch is in the boot.ini file that is shown in the first post in this thread. It makes the entire system use the PM Timer, which eliminates all timing problems.
Hope that was clear enough!
Jon
-----
The Win32 API contains other APIs such as QueryPerformanceTimer and QueryPerformanceFrequency. Basically these are application based timing systems. Now games and rendering applications use these API calls to retrieve very accurate timing information, on which they base their frame rendering and physics engines.
Some games, however, bypass the Win32 API. Instead of using this software based timing, they use a hardware based timing by calling something known as the RDTSC x86 instruction.
Now each core on a multicore system has a RDTSC (Read Time Stamp Counter) which is a bit like a clock. So, for the sake of argument, let's take a single threaded game running on a dual core system. Now the API assigns the game to Core 0. So Core 0 is processing game information like this:
TSC @ 1000 - frame 1
TSC @ 1100 - frame 2
TSC @ 1200 - frame 3
TSC @ 1300 - frame 4
Because Core Affinity is not assigned, the API can switch the game thread from one core to the other. This could be for any number of reasons, but a lot of single threaded apps will behave like this. If you run a single threaded program, you'll often notice that instead of one core being at 100% and the other being at 0%, both will hover around 50%. This is the API moving the thread constantly between cores to even out the load.
The problem appears when the API switches the thread to the other core. At frame 4 in the above example, Core 0's RDTSC is at 1300. However, Core 1's RDTSC could well be anything. Let's say it's at 1100. When this happens, as you can see, the timing is completely messed up. From the game's point of view, time has gone backwards. Only 2 frames, admittedly, but this happens continuously and is what causes stuttering and other problems.
Now for the DCO. In short, it "listens" for timing related calls either to the Win32 API or the RDTSC x86 instruction. Then, it reroutes them to a core-independent timing system (the power management timer). Therefore the game (or whatever app) works correctly, even when the API is moving the thread between cores.
As a side note, the power management timer is what the /usepmtimer switch is in the boot.ini file that is shown in the first post in this thread. It makes the entire system use the PM Timer, which eliminates all timing problems.
Hope that was clear enough!
Jon
Thanks ProfThis is a post I wrote a while back explaining how the DCO works and how and why it should make the system run better. Hope you find it useful
-----
The Win32 API contains other APIs such as QueryPerformanceTimer and QueryPerformanceFrequency. Basically these are application based timing systems. Now games and rendering applications use these API calls to retrieve very accurate timing information, on which they base their frame rendering and physics engines.
Some games, however, bypass the Win32 API. Instead of using this software based timing, they use a hardware based timing by calling something known as the RDTSC x86 instruction.
Now each core on a multicore system has a RDTSC (Read Time Stamp Counter) which is a bit like a clock. So, for the sake of argument, let's take a single threaded game running on a dual core system. Now the API assigns the game to Core 0. So Core 0 is processing game information like this:
TSC @ 1000 - frame 1
TSC @ 1100 - frame 2
TSC @ 1200 - frame 3
TSC @ 1300 - frame 4
Because Core Affinity is not assigned, the API can switch the game thread from one core to the other. This could be for any number of reasons, but a lot of single threaded apps will behave like this. If you run a single threaded program, you'll often notice that instead of one core being at 100% and the other being at 0%, both will hover around 50%. This is the API moving the thread constantly between cores to even out the load.
The problem appears when the API switches the thread to the other core. At frame 4 in the above example, Core 0's RDTSC is at 1300. However, Core 1's RDTSC could well be anything. Let's say it's at 1100. When this happens, as you can see, the timing is completely messed up. From the game's point of view, time has gone backwards. Only 2 frames, admittedly, but this happens continuously and is what causes stuttering and other problems.
Now for the DCO. In short, it "listens" for timing related calls either to the Win32 API or the RDTSC x86 instruction. Then, it reroutes them to a core-independent timing system (the power management timer). Therefore the game (or whatever app) works correctly, even when the API is moving the thread between cores.
As a side note, the power management timer is what the /usepmtimer switch is in the boot.ini file that is shown in the first post in this thread. It makes the entire system use the PM Timer, which eliminates all timing problems.
Hope that was clear enough!
Jon
Associate
- Joined
- 26 Sep 2007
- Posts
- 6
I have a dual core system and after a few weeks of use i noticed a lose of fps in a number of aps. I applied the ms hotfix and that has improved performance across the board. I have used the AMD optimiser on pervious installs (xp) and this has seemed to do much the same, so i guess its a matter of preference. I personally can't tell the difference in terms of performance.
The hotfix and installation routine over at XS is well out of date now. The most simple and straight forward thing to do is install the AMD dual core cpu driver, then install the dual core optimizer. As a sidenote, unless you install the AMD dual core cpu driver, Orthos will not run properly and will fail very quickly, the new multi-threaded version of Prime95 is the same.