ATI Multi-VPU up and running. . .
- Thread starter Geo
- Start date
Joe DeFuria said:
#1 reason why you're wrong. two identical GPUs (and I posited in my message you responded to) from different board vendors can have their clock frequencies set in sync via the driver. GPU Clock = min(gpu1, gpu2), RAM clock = min(board1, board2)
#2 Unfounded supposition. The prerequisite for same or similar boards may in fact just be to avoid busy waits and stalls. There is no hard evidence what the limitation actually is, and ATI itself appears to be recommending two of the same kinds of cards. So the assertion that ATI's solution (whatever it is, since we don't know the details of how it works) is not subject to "same board vendor", but Nvidia's ultimately *IS* (that is, can't be made to work via driver update) is unfounded.
My own supposition is that this restriction exists purely to limit support costs as customers go out and buy different vendor's boards which have different GPU versions or vastly different clocks. It simply makes sense to force the consumer to buy two of the same products, rather than support a combinatorial explosion of SLI setups and related customer service calls when invariably, some fraction of buyers *will be confused* and buy incompatible setups.
It's easy to shop for two of the same thing. Its hard for consumers to buy two different OEM boxes and ensure compatibility. Not all packaging even lists GPU, clock, and memory.
Presently NVIDIAs SLI needs the same BIOS on both boards, so even if a manufacturer changes memory supplier on the same board it will need a new BIOS and wont work with the other the boards with the other RAM (fortunate that there is only one DDR3 vendor at the moment). I think this limitation is for syncronisation for AFR modes just in case the timing of the boards are different.
A few things about the stories here though - don't be sold on the idea that it requires 32 lanes in the first place, but there are PCIe switches as well (there was a 955 board as IDF with it on). I don't think Fudo's story is correct.
A few things about the stories here though - don't be sold on the idea that it requires 32 lanes in the first place, but there are PCIe switches as well (there was a 955 board as IDF with it on). I don't think Fudo's story is correct.
I don't understand why the synchronization matters, whether SFR or AFR, no two workloads are likely to remain in sync. If you split the frame,the top and bottom could finish at different times, forcing a busy wait. If you alternate frame render, the former frame could have an easier workload than the later, in which case you busy-wait. This are likely to dominate de-synchronization, not memory bandwidth or core clock.
It seems to me, what you really want to be in sync is pixel shader versions, pixel shader precision, texel alignment, and other issues need to make shared data compatible.
It also seems intuitive to me that SFR would face more synchronization issues than AFR due to the need for both cards to arrive at a synchronization point before FB combine for display or setting an FB result as a texture.
It seems to me, what you really want to be in sync is pixel shader versions, pixel shader precision, texel alignment, and other issues need to make shared data compatible.
It also seems intuitive to me that SFR would face more synchronization issues than AFR due to the need for both cards to arrive at a synchronization point before FB combine for display or setting an FB result as a texture.
Jawed
Legend
I agree, the "identical cards" thing seems to be more marketing than about actual microsecond by microsecond timing compatibility.
After all the whole architecture of SLI is about two cards that independently compute a frame, or a portion of a frame.
The only place where "compatibility" needs to be maximised, surely, is in the SLI link connector's interfaces. It's apparent that this bit of hardware is just a dumb physical connection between the two cards. All the "logic" appears to be on die (on the NV4x chip itself).
So I suppose there's a chance that the on-die SLI-linik controller circuitry needs to be matched between cards. But that's pushing it, isn't it? Shouldn't this be an asynchronous connection?
----------
As for PEGx16 times two, it's already been shown that PCI Express cards are quite happy running with some of the lanes "blanked off" with electrical tape. I can't imagine any graphics cards are actually going to fail to operate if inserted into two PEGx8 slots.
So, where's Kaleidoscope?
Jawed
After all the whole architecture of SLI is about two cards that independently compute a frame, or a portion of a frame.
The only place where "compatibility" needs to be maximised, surely, is in the SLI link connector's interfaces. It's apparent that this bit of hardware is just a dumb physical connection between the two cards. All the "logic" appears to be on die (on the NV4x chip itself).
So I suppose there's a chance that the on-die SLI-linik controller circuitry needs to be matched between cards. But that's pushing it, isn't it? Shouldn't this be an asynchronous connection?
----------
As for PEGx16 times two, it's already been shown that PCI Express cards are quite happy running with some of the lanes "blanked off" with electrical tape. I can't imagine any graphics cards are actually going to fail to operate if inserted into two PEGx8 slots.
So, where's Kaleidoscope?
Jawed
Joe DeFuria
Legend
DemoCoder said:
One of the oft cited reasons for difficulties in buliding multi-chip boards is "sync" issues. And these are chips on the same board. Now, Take different hardware...even if they are "clocked the same" and you have a higher liklihood of running into problems. Does each card generate their clocks the same way?
Now, if you have two different manufactured boards using the same design and components, then sure...no problem.
So, we're both guilty of unfounded supposition?
Did I claim such?
Yes...appears to be. But we don't know yet and there's conflicting info out there. I t also appears that ATI's solution is pure software, which, by definition, would make any limitations we're talking about software forced.
Jesus Christ, DC. I'm making no assertions. I'm making guesses, as are you. Problem? Or should I say "your assertion that ATI's solution IS subject to "same board vendor", but nVidia's ultimately *IS NOT*, is unfounded."
1) nVidia currently enfornces "same board" for SLI. No matter what the reason you or I might guess. The actual reason isn't really all that important...and we can both make guesses as to "why". The reality is...it's a limitation.
2) We have conflicting info about ATI's implementation in terms of "likeness of card." However, one thing that appears to be the case is that it's a pure software solution.
Yes, and "your supposition" is founded...while mine is not...correct?
Why would they implement a software solution when they already have a known, proven, working hardware solution?
Because using their known, proven, working hardware solution is what everyone will be expecting them to do...DaveBaumann said:
....hssssst!
Yeah, I'm remembering that too and kind of expecting a silly season of "insider info" that is just total BS out of ATi to keep the truth a secret.tEd said:
When that starts though, will tell us something....
MoonRoach from "Cerebus" actually, but the Spanish Inquisition works too.martrox said:
Hmmm, we really should be able to work out a Spanish Inquisition/Inquirerer gag/pun with a little thought.... :|
Joe DeFuria
Legend
DaveBaumann said:
Because there are advantages to a software solution.
1) Flexibility
2) Production cost
Obviously, there are disadvantages too. I wouldn't care to guess which solution (hardware / software) makes the most sense for the consumer market, but just because you may have a hardware solution that can be effective in a professional environment, doesn't mean it can be leveraged into the consumer market.
Having said that...I'll put on my "Dave Decoder Ring" and assume you're passing a hint.
"known, proven, working" probably looks pretty enticing for a 1st gen take on it in the consumer space, particularly when all three also imply the r&d investment has already been made so why not leverage it.
The advantages that Joe perceives in a software solution might start looking more attractive gen 2, 3, etc.
The advantages that Joe perceives in a software solution might start looking more attractive gen 2, 3, etc.
DaveBaumann said:
What do you mean by hardware solution? Clearly, the bulk of the work for nV SLI is being done by drivers. If the SLI connector is just there to transfer front buffers for display, then clearly the driver is pulling all the weight through the PCI-E bus.
No matter how perfectly synced in speed the two cards are, there is simply no way, in either AFR or SFR, that both cards will finish their workloads at the same time, therefore, hardware or software, there has to be an asynchronous wait mechanism.
So again, given that cards will render their workloads at different speeds *anyway*, why the requirement for identical vendor, other than to reduce customer confusion.
I thought they had some actual silicon on the card dedicated to SLI stuff and the driver just set-up how it worked, but I could be wrong.DemoCoder said:
(I ain't banging on all cylinders today by a longshot, sickness.
)I had the impression Dave was talking about ATI's solution ("SuperTiling" on multi-chip boards), not NVidia's. However, if there's no direct way of communication between the two boards, this has to be done by software.
One big advantage of an alternate tile rendering approach is the inherent load balancing, so the software doesn't have to do that.
One big advantage of an alternate tile rendering approach is the inherent load balancing, so the software doesn't have to do that.
