Why connect the cards in SLI and Crossfire?

geo said:
Are we expecting R5xx master Crossfire samples for reviewers at the same time as the underlying R5xx cards? Any sense if some will be available at the "Tech Day" whenever that is?
Well, fortunately it won't matter to figure out lots about how the R5xx Crossfire will do.

Firstly, we can simply take a look at the TMDS in the R5xx to see if the resolution problem is fixed. For the normal Crossfire modes, we can expect performance improvements with Crossfire to be virtually identical to those of the reviewed Crossfire products (albeit perhaps with some tweaking of the game profiles for better performance, but that will be seen across the board).

It's only with SuperAA that we'll have to actually wait for products to be available to see if the same problems occur.
 
geo said:
Are we expecting R5xx master Crossfire samples for reviewers at the same time as the underlying R5xx cards? Any sense if some will be available at the "Tech Day" whenever that is?

Dunno for sure, but I don't think so, no.
 
:sigh:

It begins to appear to me that the only reason they launched now is that they have partners who are ready to sell motherboards and they needed to be able to show some reason for folks to buy them.
 
geo said:
:sigh:

It begins to appear to me that the only reason they launched now is that they have partners who are ready to sell motherboards and they needed to be able to show some reason for folks to buy them.

Nah. It doesn't make as much sense as releasing important products in stages:

Last week: Avivo
This week: Crossfire
Next week: R5xx

No biggie.
 
If they had R5xx CrossFire boards to go with that R5xx launch that'd make more sense to me. But if they don't, and they're going to have to launch R5xx CrossFire separately later anyway, then there has to be a reason for the order above rather than Avivo, R5xx, CrossFire --which would have avoided much of the negative press they got today, while still slipping in the X8xx CrossFire at the same time for those interested.
 
I'm beginning to wonder if they are going to hold off on the R520 Crossfire so they can launch it together with the new platform.
 
Dave Baumann said:
I'm beginning to wonder if they are going to hold off on the R520 Crossfire so they can launch it together with the new platform.


AAAAAAAAAAAAAAAAAAAAAAARRRRRRRRRRRRRGGGGGGGGGGGGGHHHHHHHHHHHHHHH!

I think my head's going to explode.
blowingup.gif
 
  • Like
Reactions: Geo
Karma Police said:
What new platform?

He might be referring to the RD580 mobo platform, which according to some roadmaps should have started sampling in August and should be launched in December. According to some persistent rumours, this chipset is going to have 2* PCIe x16 CrossFire support. This will be the direct competition to C51D/G and have some advantages above C51D/G (C51D/G using south and northbridge to get two PCIe x16 slots while ATi only uses the northbridge, which means one less bottleneck, and inter communication between the two slots should be faster on RD580). Oh and the most interesting rumor that has reached my ears (at the end of August) is that RD580 will have an onboard compositing engine. If this is true than mastercards won't be nescessary in the future and all PCIe ATi cards will be able to work in CrossFire mode. I just wonder what's going to be left of CrossFire support on Intels chipset if this is true.
 
madmartyau said:
AAAAAAAAAAAAAAAAAAAAAAARRRRRRRRRRRRRGGGGGGGGGGGGGHHHHHHHHHHHHHHH!

I think my head's going to explode.
blowingup.gif

QFT. And a :whimper: for good measure.

Edit: Otoh, I think Wavey just agreed with me. Tangentially, but still. :LOL:
 
Last edited by a moderator:
Dave Baumann said:
I'm beginning to wonder if they are going to hold off on the R520 Crossfire so they can launch it together with the new platform.


So this is untrue:

Anand wrote:

"Common features to all R520 based boards include the new 90nm lead free manufacturing process, a Xilleon based TV encoder, SM3.0, H.264 decode acceleration and CrossFire support."

http://anandtech.com/video/showdoc.aspx?i=2532

Edit (or does it mean that CF on the R520 boards require the new platform).
 
Last edited by a moderator:
Well you get Crossfire support by default just by having a GPU from R300 onwards, PCI Express interconnect and a DVI port. Those are the only requirements for a slave board to say "Crossfire support" on the box.

Master boards are the different kettle of fish and caboosemoose is right, there'll be no R5-series Crossfire at launch.
 
Rys said:
Well you get Crossfire support by default just by having a GPU from R300 onwards, PCI Express interconnect and a DVI port. Those are the only requirements for a slave board to say "Crossfire support" on the box.

Master boards are the different kettle of fish and caboosemoose is right, there'll be no R5-series Crossfire at launch.

Do you think this is because ATI couldn't get it to work in time, or just wanted to release it later? I think it would be bad for ATI if a customer purchased a MB and a R520, then would need to buy yet another MB for Xfire.
 
CMAN said:
Do you think this is because ATI couldn't get it to work in time, or just wanted to release it later? I think it would be bad for ATI if a customer purchased a MB and a R520, then would need to buy yet another MB for Xfire.

If I were ATI, I would do the following:

1) Include the compositing engine on the (rumored) upcoming RD580 motherboards
2) Do not produce master cards for the R5xx series graphics cards
3) Produce a separate "composting card" (el-cheapo PCI card perhaps).

This will allow the following:

1) Radeon 5xx Xfire can be done with an ATI RD580 mainboard and "any two" R5xx cards.
2) Radeon 5xx Crossfire can be done with any other crossfire supported motherboard (Current ATI XFire mobos and Intel chipset boards), with the addition of the composting card
3) Possibly be able to use R4xx Crossfire with any two R4xx cards on ATI RD580 mainboards
4) Possibly be able to use R4xx Xfire on any X-Fire mainboard with the composting card.

I think almost everyone would win this way. I think having a "composting card" would actually be cheaper in the long run than having multiple SKUs for "master cards"...and it would actually make the consumer's life easier, IMO.
 
I wonder what that connector on the X1800xl pics is for, and if it might have any relevance to this discussion. . .
 
Joe DeFuria said:
Possibly....but I don't see that happening until the R600 generation at the earliest.
Yeah, I don't expect so. But a solution that requires a particular motherboard chipset, when so many dual-slot motherboards are on the market? Or one that requires one to pay more money for a third card? SLI should seem so much more attractive.
 
Chalnoth said:
Yeah, I don't expect so. But a solution that requires a particular motherboard chipset, when so many dual-slot motherboards are on the market? Or one that requires one to pay more money for a third card? SLI should seem so much more attractive.

That all depends on if the composting chip enables additional functionality and/or flexibility.

A "composting card" should cost all of what? $10? I would think they could even build it into a special cable...who knows.
 
Dave Baumann said:
I think this is a fiarly good reason why PCIe isn't used at the moment, the performance is just too low for high resolution rendering on high end boards. Although the theory suggests 2GB/s transfer rates, the reaility is the usable bandwidth with current implementations it is much lower and I think there is also latency issues thereas well.

That being said, I wouldn't be surupised to see a bit more of a two tiered system.

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?
 
Back
Top