RD550 & RD600 Details, Dongle-less CrossFire, full HDCP support

[Arty]

Dailytech has some interesting details on ATI's upcoming chipsets.

I was confused to post it here (crossfire) or in PC Video (re: HDCP), mods move if this is in the wrong section.

 

[neliz]

Dongleless crossfire for WHICH cards exactly? so far both 13 and 1600's run dongle less crossfire, so it's no real surprise there...

 

[no-X]

What about built-in comp. engine, which would allow to use X1800/X1900 CF without dongle and master card?

 

[neliz]

What about built-in comp. engine, which would allow to use X1800/X1900 CF without dongle and master card?

Only in the 1950's and onwards

It depends, the composition engine is used to work on composing the external and internal signals right? (master card internal signal and slave's external signal) xfire on 13/1600's doesn't require a composition engine because it's travelling over PCIe instead of an external channel.

Any Chipset fast enough to feed both 1900's would automatically make the CE obsolete.
But I wonder if R580's 16x16 setup is fast enough for 1900's, sure it improves performance on the low end and mid-range, but enough for 1900's? I would like to see it, but I doubt it. That's why R590's rumoured test boards feature a link for the "sli" like bridge connector.

The problem with the "specS" of rs550 and rs600 would be that they talk about 16x8 and 8x8, basically elliminating high end dongle less configurations on those boards. right?

 

[trinibwoy]

It depends, the composition engine is used to work on composing the external and internal signals right? (master card internal signal and slave's external signal) xfire on 13/1600's doesn't require a composition engine because it's travelling over PCIe instead of an external channel.

I wasn't aware that the compositing chip had anything to do with inter-card communication - that was the dongle's job and it was there simply due to bandwidth constraints in PCIe. How does high bandwidth PCIe remove the need for the compositing functions of the add-on chip?

 

[neliz]

When ATI initially introduced the X1000 series the Crossfire support for X1300 was always due to be based on two standard cards with the data transfer occurring over the PCI Express bus, however X1600 was intended to be based on the same master/slave configuration present at the high end. Sometime after the release ATI decided on a switch such that X1600 now can operate in Crossfire mode with two standard boards and using the same data transference method as X1300 - this is likely because of the increased costs of the compositing solution wouldn't be beneficial given the performance X1600 operate at.
Although we haven't given it a full test here we can see that the Crossfire gains for X1600 in with this solution can yield fairly tangible results, with performance gains up to nearly 70% in Splinter Cell, at least. However in other games its clear that it would benefit from increased bandwidth between the two boards, which is widely expected to come with ATI's next chipset. Of course, that raises other issues with Crossfire such as it being platform specific and to take benefits of it most users will likely need a new mainboard, pushing the costs up for these entry and mainstream level solutions.

That's from the rv5xx review: http://www.beyond3d.com/reviews/ati/rv5xx/index.php?p=23

The "beneficial performance" Dave talked about is obviously found in RD580.

The Dongle does NOT communicate.
The composition engine merely "sticks" the rendered parts of the frame from the Master, together with the slave card.
All other communication (i.e. vertex data, instructions etc.) is passed over the PCIe bus. the frames (or part thereof) are sent through dongle on the 18 and 19 because of the limited bandwidth left available after inter-card communication.
The 13 and 16 simply did not require it to function properly but obviously benefit from more available bandwidth, i.e. they're reaching they're required bandwidth and probably encounter some kind of xfire QOS .
I've allready hypotisized that, should a full 16x16 product become available, it might just be marginally "fat" enough to secure proper transmission of inter-card communication on high end cards..

However, due to compatibility, even X1950's will need to work in older Xpress200 systems and thus, I think we'll see the "internal" dongle available for those as well.. maybe someone will put it on existing models as well, but it's more ATI's problem, than that of the manufacturers.

Off course, all this is sucked right out of my big thumb... but it is what I am thinking

So, nVidia used the SLI internal bridge type connector, while Ati stuck to a more VooDoo (Monster3D) esque approach

 

[Jawed]

I still think the XF mobo should have the compositing engine on it, along with a DVI/HDMI output. Put the cost entirely on the mobo.

Jawed

 

[Fodder]

That would preclude the cross-platform compatibility that I'm sure we all hope is coming.

 

[Tim]

I still think the XF mobo should have the compositing engine on it, along with a DVI/HDMI output. Put the cost entirely on the mobo.

I really don't think that makes sense from a PCIe bandwidth preservation standpoint, with a chipset compositing engine you would have to transfer half the image from card 1 and half the image from card 2 to the chipset and then the whole composeted image back to card 1. With the compositing engine on the GPU you will only need to transfer half the image from card 2 to card 1.

 

[Jawed]

That's why I said put a DVI/HDMI output on the mobo.

The nice thing about this arrangement is that the PCI-E bandwidth consumed in getting a frame from the two graphics cards has no effect on the PCI-E bandwidth required to render the following frame. 32 lanes of readback while 32 lanes of graphics data is being pushed to the two cards.

Jawed

 

[neliz]

That's why I said put a DVI/HDMI output on the mobo.

The nice thing about this arrangement is that the PCI-E bandwidth consumed in getting a frame from the two graphics cards has no effect on the PCI-E bandwidth required to render the following frame. 32 lanes of readback while 32 lanes of graphics data is being pushed to the two cards.

Jawed

And that brings back one of the original views of xfire, every processor on board could be used for xfire, the amount of available PCIe lanes per GPU dictate it's workload.

But unfortunatly, xfire isn't that mature, as to say, an onboard GPU and two cards in crossfire don't result in 5 usable screens.
crossfire would make a huge leap into the first slot when Ati' decides to have this information available over the PCIe bus.
Chipsets with 4 x16 slots for instance.

 

[Tim]

That's why I said put a DVI/HDMI output on the mobo.

That might make sense for motherboards that already has integrated graphic, but adding 4 DVI links 2 DACs and HDCP support (increased licensing cost) to the chipset just to get CF support does not make a whole lot of sense to me. Yes you do save one compositing engine - but I just can't see it as a sensible trade off.

 

[Jawed]

4 DVI links? 2 DACs? HDCP mandatory?

All the mobo needs is a single digital/analog output and a compositing chip. Whether it needs integrated graphics is arguable, but a CF-specific chipset should have whatever gubbins are required to get a video signal out of a CF implementation, leaving the individual graphics cards in an entirely standard form.

Otherwise, everyone who buys a graphics card will be paying a CF tax in functionality on the board/GPU to support mastercard-less CF.

I think the overhead should reside solely in the purchase of a CF mobo. If it's simplest to get it working by including integrated graphics plus compositing, then fine.

Jawed

 

[Tim]

4 DVI links? 2 DACs? HDCP mandatory?

All the mobo needs is a single digital/analog output and a compositing chip.

That would be terrible solution, with no TV-out, no dual screen, no HD-vidio with Bluray or HDDVD when CF is used.

 

[Jawed]

Jawed

 

[kemosabe]

I propose focusing more collective geek energy on a Xfire chipset that isn't vapourware (at least not for much longer). :smile:

 

[Tim]

Jawed

I just don't understand a ~1.5milion transistor "tax" is such a big problem that you want to limit functionality just to avoid it.

 

[Geo]

I propose focusing more collective geek energy on a Xfire chipset that isn't vapourware (at least not for much longer). :smile:

Yeah, seems Wednesday is the day. . .lot going on this week, apparently.

 

[Arty]

http://www.hardspell.com/pic/2006/2/28/75db89ce-7fef-41f9-8db6-a01ca203a3ac.jpg
http://www.hardspell.com/pic/2006/2/28/7c206cf7-c182-4e70-9fe4-cfb672a3fc76.jpg

http://www.hardspell.com/pic/2006/2/28/3f75ac78-1d8d-4344-81b6-04413c9cb5b6.jpg

 

[Fodder]

Looks like the upcoming IGP chipsets (R*6*0) are being plugged as AVIVO-capable, so I guess that spells an end to that bizarre X700 prediction that was floating around. Anyone care to lay odds on hardware vertex shading finally making an appearance?