Why connect the cards in SLI and Crossfire?

[KimB]

Except there's really no reason for a compositing chip except to support multi-card operation on chips not designed for it.

 

[KimB]

3.) Crossfire cannot hide the latency of the frame transfer.
Normally it should start the rendering of the next frame while the previous one is being composited.

I don't think this is possible, because it would mean that rendering would only occur during VBLANK.

 

[Karma Police]

From what I was able to find the RD580 sampled in Aug with a goal of production in Dec. This is for AMD systems. Intel systems so far I could find go from RD400 to RD600 in 1Q '06. Thats quite a ways away.

Compositing Engine ATi RD580

 

[Tridam]

Well I can think of 3 possible explanations:

1.) Designers of PCIe lied about it's bandwidth (fairly unlikely).

2.) Crossfire cannot perform a DMA transfer between the two cards.
That's probably a limitation of either the MB chipset or the graphics chip.
This might been solved by either moving the data to the main memory and back to the other card, or by a CPU assisted memory transfer. Either way it's slower.

3.) Crossfire cannot hide the latency of the frame transfer.
Normally it should start the rendering of the next frame while the previous one is being composited.

If I'd have to guess it's a combination of 2 and 3.

Can you maybe find out if these are the real issues holding back the implementation?

I've done many tests around SLI AA and SuperAA. Unfortunately not enough time to write a lot about it.
CrossFire and SLI can't hide the latency of the PCIE transfer. Effective rendering time = rendering time + transfer time.
CrossFire does a DMA transfer, SLI doesn't so it uses HT and main memory bandwidth and also increases the latency.

Single cycle rendering :

Nf4 SLI, 6800 Ultra, AA4x : 3260 MPix/s
Nf4 SLI, 7800 GTX, AA4x : 3252 MPix/s
Xpress200 CE, X850 XT, AA4x : 2022 Mpix/s

Nf4 SLI, 6800 Ultra SLI AA 8x : 33 Mpix/s (-> 126 Mb/s)
Nf4 SLI, 7800 GTX SLI AA 8x : 234 Mpix/s (-> 893 Mb/s)
Nf4 SLI 32, 6800 Ultra SLI AA 8x : 34 Mpix/s (-> 130 Mb/s)
Nf4 SLI 32, 7800 GTX SLI AA 8x : 286 Mpix/s (-> 1091 Mb/s)
Xpress2200 CE, X850 XT, CF Super AA 10x (= SLI AA 8x) : 128 Mpix/s (-> 488 Mb/s)

Bandwidth when getting data back from a graphic board :

Nf4 SLI, 6800 Ultra : 862 Mb/s (that’s strange because very high for a bridged solution)
Nf4 SLI, 7800 Ultra : 929 Mb/s
Xpress200 CE, X850 XT : 505 Mb/s

 

[OpenGL guy]

Except there's really no reason for a compositing chip except to support multi-card operation on chips not designed for it.

Not designed for it? You mean like the 32 R300 chip systems E&S made?

 

[Moloch]

Not designed for it? You mean like the 32 R300 chip systems E&S made?

So can you.. play games with those?

 

[trinibwoy]

CrossFire does a DMA transfer, SLI doesn't so it uses HT and main memory bandwidth and also increases the latency.

Do we know why Nvidia can't do SLI AA over the bridge?

 

[Hyp-X]

I don't think this is possible, because it would mean that rendering would only occur during VBLANK.

???

 

[KimB]

???

The compositing chip is in operation all the time, because it has no local memory. It takes the output stream from one graphics card, combines it with the second.

Still, I suppose ATI may have been forced to make a workaround for this to get it to operate across the PCIe bus for SuperAA, which is probably a render-to-texture which is then sent to the other video card for compositing. This would mean that the compositing chip would be completely idle, and the solution would effectively be a software workaround allowing two video cards to work together. If ATI is doing this, which seems rather likely on the X8xx parts, then it's rather impressive that they got it to run as quickly as they did.

 

[KimB]

Do we know why Nvidia can't do SLI AA over the bridge?

Probably because nVidia only patched-on SLI AA after the product was finished.

I would expect much better multi-card AA from both vendors for their next generation products.

 

[Hyp-X]

The compositing chip is in operation all the time, because it has no local memory. It takes the output stream from one graphics card, combines it with the second.

Still, I suppose ATI may have been forced to make a workaround for this to get it to operate across the PCIe bus for SuperAA, which is probably a render-to-texture which is then sent to the other video card for compositing. This would mean that the compositing chip would be completely idle, and the solution would effectively be a software workaround allowing two video cards to work together. If ATI is doing this, which seems rather likely on the X8xx parts, then it's rather impressive that they got it to run as quickly as they did.

I beleive this is what they do - and this is why it runs so unimpressively.

Still if the sending&compositiong was a hardware functionality of the chip instead of a software workaround, then it would be possible to do it while the next frame is being rendered - and the result framerate would be much higher.

 

[KimB]

Right, and it should only need to be a feature of the compositing chip itself, which makes one think that either this functionality is bugged in this revision of the chip, or was implemented late in development, and thus will not be seen until the next generation of Crossfire.

 

[caboosemoose]

Possibly....but I don't see that happening until the R600 generation at the earliest.

Agreed, the whole Crossfie thang appeared too late in the day for Rx5XX. Actually, it was probably pretty marginal for R600, but I would guess it will probably be in there.

As for why there wont be any Crossfire R5XX samples at the launch event - I think ATI already has its work cut out just getting a handful of functioning R520 boards together Crossfire would be a real luxury.