Intel Q9450 vs Phenom 9850 - ATI HD3870 X2

[JumpingJack]

What is the volume?

Less than what 800 Mhz FSB can support you don't need to know, you can setup an experiment to see if it matters.... I.e. change the FSB speed and see if it changes the results..... I showed you that data http://www.xtremesystems.org/forums/...6&postcount=59.

Nonetheless, the thought exercise was not about the size but how each platform retrieves a chunk of data.

I also showed you that Intel scales a multicored multithreaded game along the same curve as an AMD CPU:


However, if you want to measure it.... you can download Intel's Vtune or AMD's CodeAnalyst and monitor the counters of the bus busy line.

What I wrote was the points in 3d space is calculated and sent from the CPU. I know that DMA (http://en.wikipedia.org/wiki/Direct_memory_access) is used to load these textures etc that is used to "paint" the picture.

The vertexes are already loaded to GPU memory, changes in that geometry (such as a wall blowing up) is sent by the CPU, but the entire 3D mesh is not recalculated everytime... camera position and perspective is, and this is what the GPU uses to render the image. The GPU also stores the Z-buffer, which determines which surfaces are visible in front of one another within the perspective of the camera.

This is by design, you are correct in saying that the FSB is slow... so is HT... in fact, HT is slower than the FSB in one direction (which would be from CPU to GPU). 2000 Mhz HT line gives 2 bytes of data in one direction, or 4000 MB/sec or 4.0 GB/sec... FSB is half/duplex, giving 1333x8 in one direction or 10.6 GB/sec.... technically speaking, if data needs to get from the CPU to the GPU, Intel would provide more peak BW.

Nonetheless, GPU makers and the HW/software has evolved to move all the BW necessary components to the local memory of the GPU and design in 100 GB/sec BW from v-RAM to GPU for this very reason. All the GPU needs from the CPU is what do I need to do next (a command list, hence a command buffer).

Now, when the resolution goes up high enough and the size of the textures are larger than what can be held in VRAM, then yes... a huge performance hit is taken because now the GPU must fetch a texture it does not have from system memory across that slow FSB or HT link. I have only seen recent examples of this:
http://www.anandtech.com/video/showdoc.aspx?i=3372&p=9
http://www.guru3d.com/article/radeon...w-crossfire/11
Notice the 512 MB cards dropping like a rock going from 1900x1200 to 2560x1600 ... at 2560x1600 the textures are too large to fit into VRAM... and the reviewers correctly conclude that. This is called texture thrashing. I even provided you a link showing modern games VRAM usage earlier. The vast majority games, in fact all that I have seen so far, are able to fit a levels worth of textures into 512 Meg. Grid is the first I have seen that will exceed the 512 MB barrier -- and it only does so at 2560x1600.

If all this data would be sent to the gpu for every picture than it would be so slooooow . I think that there is enough data that is sent any way. Just look at 3d drawings that have that grid like looks. And add to that all command used to inform how to "paint" the picture

Did you even read the above post... did you not see the bottlenecking flow chart by nVidia... even nVidia argues a GPU or CPU limited scenario.

I am not sure what you are talking about in terms of 3D drawings... Ratracying? Intel is faster there to... significantly faster.

What I asked for was if there is information about latency comparing Hypertransport and the Front Side Bus?

I have not seen any study or data comparing the latency of just the bus, it has always been a convoluted measure of latency through the bus to something else. I can look for you...