Yes I have measured it.
Irrelevant, the bottleneck in a high res/high setting situation resides on the GPU/Card, not the CPU.If the game has two threads, one is writing data and one is sending data to the GPU. Some of the requests are done at the same time. Will the latency be the same as when the FSB isn’t "taken" by another request?
So here is the ticket explain an experiment we can run that will prove that it is FSB driven in the CPU under your conditions.
Again, irrelevant, the workhorse is the GPU ... it is not this issue. What you are doing is looking at a case where at 2 million pixels being rendered by the GPU results in two different platforms giving the same FPS within a few FPS. You then conclude based on some marketing PR from AMD that their IMC is the ticket.Compare this with the situation on AMD. Hypertransport for I/O (GPU traffic) and IMC for memory.
Do you know the latency for AMD when it needs to write or read data to external hardware?
You are also confused on how Intel's bus architecture works with respect to handling IO from the periphrials....
The CPU will be waiting on the GPU, the GPU is processing pixels to finish the frame. The fact is at gaming code, multithreaded, C2Q is much faster at accomplishing the task.You also know that if one game has two rendering threads, then this game needs to synchronize commands to the GPU. On C2D this would work well but on C2Q, what happens if one thread is located on one C2D and the other is located on the other C2D? (You know that C2Q is two C2D that communicates through the FSB)
Phenom has L3 cache that can synchronize four cores.
Just answer the question ... how would you prove that it is a BW or latency argument in the FSB?








Bookmarks