Microstuttering tests on ATI Radeon HD 4870 X2

[Isaac MM]

Why GRID suddently became the microstuttering benchmark tool?

[L7R]

Why GRID suddently became the microstuttering benchmark tool?

I'm wondering same. I haven't really noticed it on GRID. Actually that's the most stutter-free game I have right now. Might be because fps is pretty much always over 60 now when crossfire is actually working. It would be nice if someone has noticed that too why microstuttering is harder (or impossible) to notice when fps goes over 60? Is it because when frames are rendered even completely out of time (ie both cards get a frame almost at the same time) there's still 30fps left. Which can be considered smooth.

[gosh]

Why GRID suddently became the microstuttering benchmark tool?

Could it be threading issues in GRID?

As I understand it there are a lot of reasons why a game will “stutter” or lag
One scenario could be threadproblems.

Bottlenecks will slow down performance. Bottlenecks are created if something gets overheated with too much work and cannot handle the task.

Here are some thoughts about C2Q and threading.
C2Q is two C2D without internal communication. They communicate through the FSB. Also Intel design is done to use the FSB as little as possible because they have some latency issues (the computer is at its slowest). It is vital that the cache is used for C2D or C2Q to be speedy and that means that the hit rate needs to be very high.
If you take the C2Q which has two C2D (I call them A and B here). One thread is positioned on one core in C2D-A, and another thread is located on core in C2D-B. Then if the thread on C2D-A is moved to the other core on C2D-B it means that it will need to re-fetch all data that was stored on C2D-A L2 cache and all this data needs to go through the FSB that isn’t that fast (high latency). When the thread has moved the hit rate for cache data goes down until data has been processed. This traffic in the FSB also need to handle I/O graphics and that may slow it down more, maybe switching in the Northbridge takes extra time. So for a fraction(?) of a second the C2Q is slowed until data in cache is refilled and the FSB gets up speed again because there isn’t any queue of data that needs to be sent or retrieved.
If this is the case than microstuttering (or FSB-stuttering)could be a problem that is related to games that scales to a lot of cores and use some memory.

All processors are more or less sensitive for switching treads to other cores (of course it depends on how much memory they are using). I think that Vista is NUMA aware and Phenom supports that. That is a technique to add some intelligence on where threads are placed in order to optimize memory latency. I know that there are some who say that NUMA doesn’t get any advantages but it is very hard to measure the performance gain with it because it isn’t that often the no-NUMA is hurt with issues like the one described. But this microstuttering (or I/O problem in this case) could be something that is solved with NUMA. I think that Nehalem is going to have NUMA and I don’t think that Intel put it there for fun.
Also both Nehalem and AMD Phenom isn’t as sensitive for un-optimized threading as C2D and C2Q.

[gallag]

Could it be threading issues in GRID?

As I understand it there are a lot of reasons why a game will “stutter” or lag
One scenario could be threadproblems.

Bottlenecks will slow down performance. Bottlenecks are created if something gets overheated with too much work and cannot handle the task.

Here are some thoughts about C2Q and threading.
C2Q is two C2D without internal communication. They communicate through the FSB. Also Intel design is done to use the FSB as little as possible because they have some latency issues (the computer is at its slowest). It is vital that the cache is used for C2D or C2Q to be speedy and that means that the hit rate needs to be very high.
If you take the C2Q which has two C2D (I call them A and B here). One thread is positioned on one core in C2D-A, and another thread is located on core in C2D-B. Then if the thread on C2D-A is moved to the other core on C2D-B it means that it will need to re-fetch all data that was stored on C2D-A L2 cache and all this data needs to go through the FSB that isn’t that fast (high latency). When the thread has moved the hit rate for cache data goes down until data has been processed. This traffic in the FSB also need to handle I/O graphics and that may slow it down more, maybe switching in the Northbridge takes extra time. So for a fraction(?) of a second the C2Q is slowed until data in cache is refilled and the FSB gets up speed again because there isn’t any queue of data that needs to be sent or retrieved.
If this is the case than microstuttering (or FSB-stuttering)could be a problem that is related to games that scales to a lot of cores and use some memory.

All processors are more or less sensitive for switching treads to other cores (of course it depends on how much memory they are using). I think that Vista is NUMA aware and Phenom supports that. That is a technique to add some intelligence on where threads are placed in order to optimize memory latency. I know that there are some who say that NUMA doesn’t get any advantages but it is very hard to measure the performance gain with it because it isn’t that often the no-NUMA is hurt with issues like the one described. But this microstuttering (or I/O problem in this case) could be something that is solved with NUMA. I think that Nehalem is going to have NUMA and I don’t think that Intel put it there for fun.
Also both Nehalem and AMD Phenom isn’t as sensitive for un-optimized threading as C2D and C2Q.

So this is actually an Intel thing? I see that is the theory you are pushing on AMDzone. Interesting

[gosh]

So this is actually an Intel thing? I see that is the theory you are pushing on AMDzone. Interesting

It's probably more than one reason why Intel put so much work into Nehalem Sooner or later bottlenecks on Core 2 will show. Threaded games are one area where it could be a lot of problems if they scale a bit too much.

[Aberration]

So this is actually an Intel thing? I see that is the theory you are pushing on AMDzone. Interesting

And also at http://www.hardforum.com/showthread.php?p=1032761583

For such an untested theory, sure is being plastered everywhere.

[gosh]

And also at http://www.hardforum.com/showthread.php?p=1032761583

For such an untested theory, sure is being plastered everywhere.

Prove me wrong then! I can’t prove it and you can’t prove that isn’t an issue. I have tried to get some to prove me wrong informing about these issues but none has done that.

[Aberration]

Prove me wrong then! I can’t prove it and you can’t prove that isn’t an issue. I have tried to get some to prove me wrong informing about these issues but none has done that.

Yeah, lets just seperate from science here. I have no reason to try and prove something wrong, when no effort has been done to even show its plausible.

Fact is. If your 'theory' was correct, then we would see the same problem with the 4870.

[gosh]

Yeah, lets just seperate from science here. I Fact is. If your 'theory' was correct, then we would see the same problem with the 4870.

And we don't?
Read #185. What I have seen from GRID is that it scales well and are very intensive in graphics. Also car games need a flow more than others I think. You will notice when the flow isn't there more easily.