• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

CPU bottlenecking graphics card?

I monitor if any single core reaches 100%.
I have done this on many machines including quad cores, not just my C2D.
Granted I graph with either Rivatuner or ATItools when I monitor CPU use, are you saying there is an issue with using Task Manager to monitor CPU use?

ps increasing AA can also require more CPU so that isnt a definitive test.
 
I monitor if any single core reaches 100%.
I have done this on many machines including quad cores, not just my C2D.
Granted I graph with either Rivatuner or ATItools when I monitor CPU use, are you saying there is an issue with using Task Manager to monitor CPU use?

*HOW* are you monitoring if a *SINGLE* thread uses 100% of one core?

But again, you still don't know what that thread is doing. I can have a thread that is for all intents and purposes idle while still using 100% of the core. If the thread is polling, for example, more CPU speed won't do squat.

ps increasing AA can also require more CPU so that isnt a definitive test.

No it doesn't. AA is entirely on the GPU, there isn't any CPU work with AA.
 
I'm not monitoring single threads but CPU cores.

Regarding AA and higher CPU use, I did some tests with CPU @ 100% to illustrate a game that gets almost no reduction in fps and one that gets a reduction in fps that may matter to some.

Its not straight forward to test for this.
If GPU limited, increasing AA drops framerate and thus drops CPU use also.
So it needs to be tested when CPU limited and the graphics card is under utilised.
To do this I slowed my CPU down and ran benchmarks with 0xAA and max AA.
Note: the CPU was maxed 100% and the GPU was not maxed, even when running max AA.
(both benchmarks were run once before the test start to make sure they were cached so the results wont be skewed by first run fps drop)


Crysis Warhead, CPU @ 2GHz, crossfire 5770
ambush flythrough, 1920 x 1080, gamer setting, DX9
0xAA = 28.73
8xAA = 28.22
= 1.8% slower with AA

Batman AA, CPU @ 1.2GHz, crossfire 5770, 1080p, all settings to max
max, min, avg
0xAA = 6, 82, 47
16xAA = 1, 76, 44
avg = 6.8% slower with AA

There is a noteworthy drop in framerate with Batman and other games.
The remedy is a faster CPU if framerate is too low.
 
You can't accurately monitor CPU cores, that's the point. The OS may routinely swap a single thread between multiple cores, which in task manager on a dual core setup may look like two threads are running, each using only 50% or 25% on a quad core or ~15% on a quad core with hyperthreading and that single thread may be CPU bound in each of those scenarios with none of them showing even a single core fully loaded. And we're only dealing with a single thread, most games now are multi-threaded, how do you propose to figure that out with task manager? You can't.
 
You can't accurately monitor CPU cores, that's the point...

Bizarre statement, I can accurately monitor CPU cores + I dont need to track threads, see the first line of my last post!
I'm not bothered by thread occupancy or affinity, just whether the game causes a core to become excessively loaded.
As I am monitoring CPU cores and not tracking threads, my easy test works very well without your added complexity :)
 
:rolleyes: I give up, clearly you don't understand the fact that your method is fundamentally flawed. That's fine, go with it. I just hope you stop spreading bad advise that will cause people to waste their time and possibly money.
 
:rolleyes: I give up, clearly you don't understand the fact that your method is fundamentally flawed. That's fine, go with it. I just hope you stop spreading bad advise that will cause people to waste their time and possibly money.

Prove your case, I have proved mine but even then you ignore the results and twist the debate to a different issue.
 
You haven't proven anything. You explained how you test and we explained to you why it's flawed. You not understanding is your problem, not ours. Carry on.
 
I guess reading is a issue, I demonstrated and proved my case just 5 posts above yours, nicely ignored :).
 
I fail to see how AA tests have anything to do with using task manager as an accurate way to measure a CPU bottleneck.

It was ignored because of it's irrelevancy, not because you're right.
 
A CPU bottleneck by definition is when a CPU is not available to service more requests, so when it is running at 100%, something else has to slow down if you try to increase the workload.
Numerous handy tools exist to monitor CPU use, are you saying that they dont accurately monitor CPU use?
 
A CPU bottleneck by definition is when a CPU is not available to service more requests, so when it is running at 100%, something else has to slow down if you try to increase the workload.
Numerous handy tools exist to monitor CPU use, are you saying that they dont accurately monitor CPU use?
a cpu can be a bottleneck long before it hits 100% usage. there are plenty of games where my cpu usage is only 70% but I will still get a boost by overclocking my cpu. some games could perform better on quad even if it wasnt even near 100% usage on a dual core.also some games are just faster on certain cpus like i7/i5 than they are on other quads but that doesnt mean the other quads were pegged at 100%.
 
Yes I agree that a CPU can bottleneck in other ways, ie the faster it runs the less latency there is.
However, it doesnt detract from the test I use which is to see if any core is running at 100% while gaming as this does slow framerate.
I havent said it tests for other scenarios.

The points about quad/dual core were addressed earlier.
Of course CPUs with less latency (at same clock speed) either due to internal architecture or external supporting components, or faster clock speed (on the same architecture) will run faster.
That has nothing to do with the test as it can be run on any CPU.
If a core has reached 100% while gaming, it becomes a bottleneck, regardless of CPU.
 
A CPU bottleneck by definition is when a CPU is not available to service more requests, so when it is running at 100%, something else has to slow down if you try to increase the workload.
Numerous handy tools exist to monitor CPU use, are you saying that they dont accurately monitor CPU use?

What i'm saying i've repeated several times already. The fact that you're still asking the same question some 50 posts later shows that what I and others are saying isn't registering with you. You've convinced yourself your correct and think you have it figured out and that obviously isn't going to change.
 
What i'm saying i've repeated several times already. The fact that you're still asking the same question some 50 posts later shows that what I and others are saying isn't registering with you. You've convinced yourself your correct and think you have it figured out and that obviously isn't going to change.

I have demonstrated my case and shown that it is worth considering.
I have also used it more times than I can count with success.
You are denying it and cannot give any reasons that are actually applicable.
Despite this you keep on and on.

Prove your case if you are so determined that this method cannot work.
I know it works, so all I can do is shrug at you at the moment.
 
What i'm saying i've repeated several times already. The fact that you're still asking the same question some 50 posts later shows that what I and others are saying isn't registering with you. You've convinced yourself your correct and think you have it figured out and that obviously isn't going to change.


...
 
??
I asked if there is something amiss with the CPU monitoring tools as you both are saying that CPUs wont be monitored effectively.
I havent received an answer yet.
 
??
I asked if there is something amiss with the CPU monitoring tools as you both are saying that CPUs wont be monitored effectively.
I havent received an answer yet.

I've enumerated the many issues with your "test" (which you never really described in detail), you ignored all the points and claimed to have proven something you never even posted evidence for.

What you are doing is akin to voodoo. You looked at a measurement (an approximate one at that), observed a casual relationship between it and a bottleneck, and then claimed that its proven, factual, and can be relied upon. And then when flaws are pointed out you simply ignore them and claim that it works anyway.

Thus, I'm done responding. If you want to actually *learn*, let me know and I'll try again to explain why it doesn't work. Otherwise, I'm not going to waste my time.

Again, I'm saying this as a developer who has worked with threading and OpenGL (and a *bit* of DirectX). I've even worked on kernel code. I have real experience and knowledge with what we are talking about. If you don't care, fine, whatever, but this thread is just going in circles at this point.
 
Nenu, my job for the past year or so has been spent architecting and coding hard real-time multi-threaded software for low-level comms to all sorts of devices (everything from UDP to VME to UARTs to CANBus to proprietary middleware comm systems to.....). I'm hardly an expert at processor loading and multi-threading, but you could say I'm somewhat familiar with it.

With that said, the people who are saying that you're clueless are right.

For all you know some silly coder put in a very low priority thread for something like polling for a UDP packet whenever there's a spare processor cycle. You're sitting at 100% CPU usage... but... that thread is causing 90% of it. Whereas you think you need a faster CPU, proper analysis would show that you already have waaay more processing power than is needed. For example, you could reduce a 3ghz processor to 600mhz and *still* have the low-priority polling thread using 50% of the CPU time! But you'd be sitting there running a processor 5-10 times faster than it needs to be, yet you would *still* think it's the bottleneck.
 
If the CPU or a core is fully occupied, it is practically certain that higher speed CPU would give a higher workload, thus the CPU has become a bottleneck.
This means not enough CPU time is available to service the GPUs and results in a drop in framerate.
Its so easy to demonstrate as well, Im baffled how this simple test can be so confusing for you.

I even did make a demonstration showing this effect in post #43.
 
I've enumerated the many issues with your "test" (which you never really described in detail), you ignored all the points and claimed to have proven something you never even posted evidence for.

What you are doing is akin to voodoo. You looked at a measurement (an approximate one at that), observed a casual relationship between it and a bottleneck, and then claimed that its proven, factual, and can be relied upon. And then when flaws are pointed out you simply ignore them and claim that it works anyway.

Thus, I'm done responding. If you want to actually *learn*, let me know and I'll try again to explain why it doesn't work. Otherwise, I'm not going to waste my time.

Again, I'm saying this as a developer who has worked with threading and OpenGL (and a *bit* of DirectX). I've even worked on kernel code. I have real experience and knowledge with what we are talking about. If you don't care, fine, whatever, but this thread is just going in circles at this point.

I'm sorry you feel the solution isnt technical enough but it doesnt need to be.
See my previous post for more info.
 
If the CPU or a core is fully occupied, it is practically certain that higher speed CPU would give a higher workload, thus the CPU has become a bottleneck.
This means not enough CPU time is available to service the GPUs and results in a drop in framerate.
Its so easy to demonstrate as well, Im baffled how this simple test can be so confusing for you.

NO IT DOES NOT

Again, the measurement you are trying to do is *NOT POSSIBLE* with the method you are describing. I'm baffled at how stubborn you are to listen to reason and logic.

I even did make a demonstration showing this effect in post #43.

No you didn't, you showed the effects of AA on a CPU bottlenecked game, which is exactly the test everyone else suggested. You demonstrated that when you are CPU bottlenecked increasing AA has a negligible affect on FPS. I think you were actually trying to prove that AA was somehow limited by CPU speed as well, but you completely failed at that.
 
You can lead a horse to water but you can't make it drink. I think that sums up this thread quite well.
 
NO IT DOES NOT

Again, the measurement you are trying to do is *NOT POSSIBLE* with the method you are describing. I'm baffled at how stubborn you are to listen to reason and logic.



No you didn't, you showed the effects of AA on a CPU bottlenecked game, which is exactly the test everyone else suggested. You demonstrated that when you are CPU bottlenecked increasing AA has a negligible affect on FPS. I think you were actually trying to prove that AA was somehow limited by CPU speed as well, but you completely failed at that.

The test also demonstrated that if you put an extra load (AA) on an already fully occupied CPU, then framerate will drop and indeed it did, you are blind!
I gave 2 examples, one where the fps drop wasnt significant enough to matter and another example where a noteworthy speed drop occured when using AA.
 
Nenu, from seeing this thread, I'm still not sure if you're

A) A troll.
B) Proud of your ignorance.

Personally I'm not sure that it matters which it is. However, if it's A, then let me be the first to congratulate you on a job well done.
 
The test also demonstrated that if you put an extra load (AA) on an already fully occupied CPU, then framerate will drop and indeed it did, you are blind!
I gave 2 examples, one where the fps drop wasnt significant enough to matter and another example where a noteworthy speed drop occured when using AA.

A 7% FPS drop when going from 0xAA to 16xAA is not even in the same neighborhood as significant or noteworthy. Heck, depending on your testing methodology 44fps vs. 47fps could easily be margin of error, especially with CF. For all I know your email client decided to do a background update during your test. In a GPU limited scenario that sort of drop is what you would see with 2xAA.

But regardless, you claimed that post #43 supported your CPU usage test when quite clearly it has nothing to do with your CPU usage test. Thus far you have yet to actually counter anyone's arguments other than to say "No it totally works. See? I proved it." without, you know, actually proving it or even posting evidence supporting it. Hell, you still haven't even posted what exactly you monitor and *HOW* you monitor it, you just make vague claims about monitoring CPU cores.
 
A 7% FPS drop when going from 0xAA to 16xAA is not even in the same neighborhood as significant or noteworthy. Heck, depending on your testing methodology 44fps vs. 47fps could easily be margin of error, especially with CF. For all I know your email client decided to do a background update during your test. In a GPU limited scenario that sort of drop is what you would see with 2xAA.

But regardless, you claimed that post #43 supported your CPU usage test when quite clearly it has nothing to do with your CPU usage test. Thus far you have yet to actually counter anyone's arguments other than to say "No it totally works. See? I proved it." without, you know, actually proving it or even posting evidence supporting it. Hell, you still haven't even posted what exactly you monitor and *HOW* you monitor it, you just make vague claims about monitoring CPU cores.

The 6.8% is definitely outside the margin for error, I dont get a large variance on sequential runs after the first run.
The first run was discarded as stated.

I have presented my argument that if a core the game is using is fully loaded then it will start to reduce framerate, and will continue to reduce framerate if the available CPU is further reduced.
Thus if a faster CPU is used, you can increase framerate.

You seem to think it matters if threads switch between cores in this context of seeing if a core is bottlenecking framerate.
It matters not at all.
If a core is fully loaded, it can do no more, no matter which thread(s) are running on it.
If that 100% utilised core is used by the game and you run more on that core (at the same priority), it will reduce available CPU for the game and thus framerate will drop.

Note:If a thread jumps to another core reducing CPU use well below 100%, then clearly it falls out of the context of what we are discussing so that is not pertinent.
This discussion is about how a CPU 'can' bottleneck the graphics card.

I have provided a very good demonstration that even using AA can cause framerate to drop in a "CPU limited, non GPU limited" environment, that is the effect of reducing available CPU.
6.8% can be significant, some people pay a lot of money to get less than that improvement!
It wasnt the significant point though, that value is arbitrary.
The main point is that 100% on a core while gaming will bottleneck framerate.
Therefore if suffering framerate problems, its worth seeing if the CPU or any core is running 100%.
 
Last edited:
Nenu, from seeing this thread, I'm still not sure if you're

A) A troll.
B) Proud of your ignorance.

Personally I'm not sure that it matters which it is. However, if it's A, then let me be the first to congratulate you on a job well done.

Sadly I don't think he's a troll. It's either B or he simply lacks the mental capacity to understand why his method is flawed. Now that may seem like an insult, but it isn't. Everyone lacks mental capacity for certain things. I lack the mental capacity to learn Spanish, despite talking no less than 2 years worth of classes and having many hispanic friends. Ignorance plays a part either way though, I'm fully aware of my limitation while he thnk's he's correct and everyone else is wrong. There is no doubt in my mine that he's going to reply to this saying the same things he's said for the last several posts in this thread.
 
The test also demonstrated that if you put an extra load (AA) on an already fully occupied CPU, then framerate will drop and indeed it did, you are blind!
I gave 2 examples, one where the fps drop wasnt significant enough to matter and another example where a noteworthy speed drop occured when using AA.

Is true that the frame rate will drop if you turn on anti aliasing, but is because you are GPU bound in such scenario, Anti Aliasing has nothing to do with the CPU, Anti Aliasing resolve is done by the GPU's ROP or Shader processor. When you are CPU bound, turning On anti aliasing will not result in a drop of performance at all.

About bottlenecks, it all depends of the type of workload and the architecture/processor itself. Good example, the Pentium M vs the Pentium 4. I own a desktop with a 3.2GHz Northwood processor and 2GB of RAM and Windows 7. I ran Linpack and used the desktop for another tasks, and the computer was slow, but still usable.

But the laptop that I have has a Pentium M CPU running at 2.0GHz with the same 2GB of RAM in dual channel and Windows 7, running linpack and using the desktop was more usable than before, even though the Pentium 4 has a higher clock speed, why? Because the Pentium M execution engine is wider and is even more optimized for maximization of utilization than Current Core 2 architecture which its front ends goes underutilized most of the time because it is wider and is harder to keep it fed, but the Pentium M has a weaker FPU. In benchmarks which requires lots of branchy code, Pentium M is faster than any Pentium 4, up to 3.73GHz, but in linear code like video encoding, Pentium 4 is just faster.

I can find lots of scenarios that I can play any game that I want along with encoding a MPEG4 1080p video from a bluray movie with Nero Vision which uses all four threads of my Quad Core near to 90% and I can't feel any slowdown at all, while there's some scenarios like encoding the same file to WMV 1080p using Nero Vision and the WMV 10 Pro Codec and the game would slow down considerably, with the same CPU usage. Linpack uses 100% of the CPU, and it slowdown the system that other type of tests like Prime95 or OCCT, which also uses the 100% of the CPU.

In the end, the story is that the CPU can be a bottleneck depending of the type of load, architecture and scenario, just like in games, a Dual Core can be enough for most games currently, but might not be enough for GTA4 or Mass Effect which uses all four cores equally. If something that I posted is wrong, just correct me :)
 
Is true that the frame rate will drop if you turn on anti aliasing, but is because you are GPU bound in such scenario...

The scenario under discussion and the test I performed are when the CPU is fully loaded and GPU does not get fully loaded.
It is the question the OP asked.
I dropped my CPU speed to achieve this, I hoped it was clear.

I can create a graph screen capture from ATItools of Batman, showing CPU and GPU use and will give the max, min avg framerates with 0xAA and 8xAA if you wish?
It will show that GPU use increases substantially with AA but framerate drops, the GPU doesnt get anywhere near max use.
I have hopefully given enough information for anyone else to try it as well.
 
The 6.8% is definitely outside the margin for error, I dont get a large variance on sequential runs after the first run.
The first run was discarded as stated.

I have presented my argument that if a core the game is using is fully loaded then it will start to reduce framerate, and will continue to reduce framerate if the available CPU is further reduced.
Thus if a faster CPU is used, you can increase framerate.

You seem to think it matters if threads switch between cores in this context of seeing if a core is bottlenecking framerate.
It matters not at all.
If a core is fully loaded, it can do no more, no matter which thread(s) are running on it.
If that 100% utilised core is used by the game and you run more on that core (at the same priority), it will reduce available CPU for the game and thus framerate will drop.

Note:If a thread jumps to another core reducing CPU use well below 100%, then clearly it falls out of the context of what we are discussing so that is not pertinent.
This discussion is about how a CPU 'can' bottleneck the graphics card.

I have provided a very good demonstration that even using AA can cause framerate to drop in a "CPU limited, non GPU limited" environment, that is the effect of reducing available CPU.
6.8% can be significant, some people pay a lot of money to get less than that improvement!
It wasnt the significant point though, that value is arbitrary.
The main point is that 100% on a core while gaming will bottleneck framerate.
Therefore if suffering framerate problems, its worth seeing if the CPU or any core is running 100%.

I seriously want to reach through the screen and choke you, you are incredibly frustrating to deal with.

HOW THE FUCK ARE YOU MONITORING THE LOAD OF A CORE?!?!?! (assume a quad core when you are explaining EXACTLY what you do)

As soon as you answer that, I'll explain why what you are doing doesn't work.

And I think you missed the part about a 7% drop being incredibly small going from 0xAA to 16 mother fucking AA. That pretty much points to being CPU limited extremely clearly. And again, AA is entirely GPU based, despite what you want to believe.
 
man you guys are really dogging it out over here in this thread lol.


so guess what i decided to get a q9550 and a 5850.

problem solved!:cool::cool::cool:
 
man you guys are really dogging it out over here in this thread lol.


so guess what i decided to get a q9550 and a 5850.

problem solved!:cool::cool::cool:
good and thread closed until you get your next gpu upgrade and we tell you to with i5/i7 . :p
 
I think the idea of checking CPU usage is an oversimplified test which is flawed.

The reason for this is that some games use multiple threads and execute on multiple cores, you'd need to have a very deep understanding of exactly how the game is multithreaded before you could make any decent decisions about if it's CPU bottelnecked or not.

Having said that a great many engines still only use 1 core or have incredibly simple multithreading like they just switch out audio, AI or physics to worker threads which feed back to the primary engine, often the work they're expected to do is pretty small which is why no real thread management is needed, as long as they're not running on the same core as the primary thread it's a bonus.

So it's a half arsed test and you can gauge basic results from it with a lot of games, especially older ones, and if you know a bit about the engine you're running you can probably estimate CPU bottlenecking on modern engines due to the simplicity of the thread mangement.

HOWEVER, there are more reliable tests that can be run, vary the GPU load and see if overall frame rate is effected, as previously explained. The debate should end here, we have an easy to run a test which is certainly more reliable.

Nenu you have to understand that we're in a change between single cores/thread and moving towards having many more cores, 2 and 4 is just the start and your method while it might work in an approximate way for a lot of older games its generally a lot less reliable than alternative methods. Soon we'll have engiens executing threads whos sole job is to distribute work to other threads as the number of cores gets very large.

The rest of you have to realise that Nenus method while maybe a bit crude does work as a good approximation for a lot of games, they either have a single thread on a single core or a master thread which runs most of the engine code with a couple of worker threads, and the master thread tends to have the most severe work load, when it hits 100% usage of a single core it's a good bet you're CPU limited.

I personally think it wont remain a good approximation for long, multithreading will get a lot more complex as the number of cores doubles a few more times (8,16), I'm personally all for promoting a better solution if one exists, which it clearly does here.
 
Last edited:
I seriously want to reach through the screen and choke you, you are incredibly frustrating to deal with.

HOW THE FUCK ARE YOU MONITORING THE LOAD OF A CORE?!?!?! (assume a quad core when you are explaining EXACTLY what you do)

As soon as you answer that, I'll explain why what you are doing doesn't work.

And I think you missed the part about a 7% drop being incredibly small going from 0xAA to 16 mother fucking AA. That pretty much points to being CPU limited extremely clearly. And again, AA is entirely GPU based, despite what you want to believe.

I literally lol'd when I read this. Classic.
 
I seriously want to reach through the screen and choke you, you are incredibly frustrating to deal with.

HOW THE FUCK ARE YOU MONITORING THE LOAD OF A CORE?!?!?! (assume a quad core when you are explaining EXACTLY what you do)

As soon as you answer that, I'll explain why what you are doing doesn't work.

And I think you missed the part about a 7% drop being incredibly small going from 0xAA to 16 mother fucking AA. That pretty much points to being CPU limited extremely clearly. And again, AA is entirely GPU based, despite what you want to believe.

Jesus guys, why the attitudes, its a simple test that has worked for me a lot.
I'm hardly going to say it hasnt worked am I ? !!
I use Rivatuner and its CPU plugin to monitor and graph individual cores.
I already mentioned the tools I use.

Pls explain the fps drop when enabling AA in a non GPU limited environment.
Extra CPU 'is' required for AA, its not completely free.
 
I think the idea of checking CPU usage is an oversimplified test which is flawed.

The reason for this is that some games use multiple threads and execute on multiple cores, you'd need to have a very deep understanding of exactly how the game is multithreaded before you could make any decent decisions about if it's CPU bottelnecked or not.

Having said that a great many engines still only use 1 core or have incredibly simple multithreading like they just switch out audio, AI or physics to worker threads which feed back to the primary engine, often the work they're expected to do is pretty small which is why no real thread management is needed, as long as they're not running on the same core as the primary thread it's a bonus.

So it's a half arsed test and you can gauge basic results from it with a lot of games, especially older ones, and if you know a bit about the engine you're running you can probably estimate CPU bottlenecking on modern engines due to the simplicity of the thread mangement.

HOWEVER, there are more reliable tests that can be run, vary the GPU load and see if overall frame rate is effected, as previously explained. The debate should end here, we have an easy to run a test which is certainly more reliable.

Nenu you have to understand that we're in a change between single cores/thread and moving towards having many more cores, 2 and 4 is just the start and your method while it might work in an approximate way for a lot of older games its generally a lot less reliable than alternative methods. Soon we'll have engiens executing threads whos sole job is to distribute work to other threads as the number of cores gets very large.

The rest of you have to realise that Nenus method while maybe a bit crude does work as a good approximation for a lot of games, they either have a single thread on a single core or a master thread which runs most of the engine code with a couple of worker threads, and the master thread tends to have the most severe work load, when it hits 100% usage of a single core it's a good bet you're CPU limited.

I personally think it wont remain a good approximation for long, multithreading will get a lot more complex as the number of cores doubles a few more times (8,16), I'm personally all for promoting a better solution if one exists, which it clearly does here.

Thank you PrincessFrosty, someone who talks sense and with respect :)

I entirely agree with your final statement.
This test is currently a good approximation with current games, it has been a very reliable indicator so far.
However in the future, some Games will likely have threads that run independent of the main game thread, thus if they stall, it wont slow fps down but will affect game mechanics instead - for example.
At the moment I havent found a game that doesnt momentarily stall when a core in use by the game has its availability reduced.
I wouldnt have recommended the OP use a test that doesnt work, its good that all this is coming out though.
I am dismayed at the conduct of some forum members though!
 
Jesus guys, why the attitudes, its a simple test that has worked for me a lot.
I'm hardly going to say it hasnt worked am I ? !!
I use Rivatuner and its CPU plugin to monitor and graph individual cores.
I already mentioned the tools I use.

HOW HOW HOW HOW HOW?

I've asked it like a bajillion times now and all you do is say what tool - that is a what not a HOW. Explain step by step exactly what you look at and watch and HOW you determine if one core is fully loaded. Explain it as if I was a child, because I'm having a hard time following your guesses at how a computer works since I know how it actually does.

Pls explain the fps drop when enabling AA in a non GPU limited environment.
Extra CPU 'is' required for AA, its not completely free.

Easy, at some point during your run through you became GPU limited, or you were CPU limited at 0xAA but GPU limited at 16xAA (which is a freaking HUGE jump in AA). That probably also explain why your min FPS went from 6 to 1. AA doesn't use a CPU at all - it just doesn't. AA is a GPU operation. I really don't know how to make it any clearer.
 
Back
Top