Dual Graphics Cards -- Alternating frames

[Butcher]

I understand why the push-buffer is there (to handle the asynchrony between the two processes: CPU and GPU. Apparently the central issue involves the "graphics port", which (under the approach I mentioned previously, where the port is handled by a special DMA controller on the graphics board) would always be free. That is, any data thrown at the graphics port by the CPU would immediately be snatched up by the DMA controller on the graphics board -- so the CPU would never have to "wait". Rather, the CPU just throws the commands at the graphics port as fast as it can, and the DMA controller will keep up. This requires zero overhead for the CPU. Also, since the graphics would be maintaining the push-buffer, the GPU could begin processing it whenever it is ready, rather than have to "wait" for the push-buffer to be brought-in in its entirety. I see this approach as a win-win situation for the CPU & GPU.

If I understand you right, you're saying there's something about the graphics port that (under the approach I suggested) would cause it to be slow and thereby cause the CPU to "wait". I don't yet see that as the case. Can you see my reason why?

The graphics port is the PCI-E or AGP bus. They are slow. What causes it to be slow is the design of the bus. They are slow because that's how they are designed. Unfortunately making very low latency busses of that nature is expensive and difficult, so it's just not going to happen.

Note, that you don't have to fill a full frame of data or such before moving data from the push buffer to the GPU. It's common to start the DMA as soon as possible so that the GPU can be reading from the buffer well before the CPU has completed writing the frame's data. The only restriction is that if the GPU catches up to the CPU it will have to stall until the CPU generates more commands.

]So the current approach actually has 1 (or 2 with SLI-AFR-mode) levels of buffering on the CPU side, plus another level of buffering on the GPU side -- for up to three levels of buffering. While I'm suggesting (perhaps yet naively) the elimination of buffering on the CPU side, and one level of buffering on each graphics card.

More levels of buffering isn't neccessarily slower. Stuff is moving through all these buffers in parallel, the overall effect is to hide the disparities in latency of the various parts of the system such that it's faster overall.

It is my understanding that the PCI-express bus (unlike the traditional PCI bus) is a dedicated point-to-point bus, where the CPU speaks directly to the graphics card with no other contingencies or delays to worry about. Under that arrangement, and with the DMA controller on the graphics board like I mentioned, I don't see how this could possibly be slower than the current approach -- that is, the CPU simply throws data at the graphics port as fast as it can, and it all works with no "waiting" and no delays. Is there something about the PCI-express bus that I'm not understanding here?

PCI-E is not zero-latency. It's a bus like most others - to start a transaction takes a fairly large amount of time. Once the transaction is started the data will flow very quickly. this is why buffering up lots of commands is good - it allows you to have nice large bus transactions to minimise the amount of hit you take for starting transactions.

You guys are pretty much forgetting the graphics driver here, from what I can tell, in your discussion on how GPU's communicate during multi-GPU rendering. The current approach isn't CPU -> buffer -> GFX Port -> FIFO -> GPU, unless buffer = driver and GFX Port goes away.

As for PCI Express, it's high latency. So high bandwidth (or you'd think so given the spec), but starting a bus transaction and getting the first bits of data to something on the other end of the bus is lots of cycles. Kind of sucky when doing real-time 3D.

So forget the CPU just DMA'ing to the graphics hardware on its own, or via a buffer, unless you mean via the driver too, which is keeping the command stream in system memory, and is preparing and storing other data at the same time.

The push buffer is managed by the driver, so yes buffer = driver in my description. By GFX port I basically mean the PCI-E or AGP bus.
The command stream kept (by the driver) in system memory is called the push buffer.

[Rys]

The push buffer is managed by the driver, so yes buffer = driver in my description. By GFX port I basically mean the PCI-E or AGP bus.
The command stream kept (by the driver) in system memory is called the push buffer.

Cool, I'm on the same page as you now