PCI Express SLI by Alienware!
- Thread starter skoprowski
- Start date
aaronspink said:
Mmmm, that suggest to me that the overall PCI-Express x16 bandwidth available to the nortbridge is going to be shared between the two graphics cards. Unless I'm reading that wrong
Yes, do you think that would be a bottleneck? 
One thing that would be interesting is if you could give commands to copy the data stream from CPU to both cards. Good for pushing a texture from CPU.
Or transfer data directly from card to card through the hub. Good for transfering textures generated on GPU.
I guess that would need help from the gfx IHV with the drivers. But it could be hard to make render to texture work at all.
One thing that would be interesting is if you could give commands to copy the data stream from CPU to both cards. Good for pushing a texture from CPU.
Or transfer data directly from card to card through the hub. Good for transfering textures generated on GPU.
I guess that would need help from the gfx IHV with the drivers. But it could be hard to make render to texture work at all.
Just incase anyone hasn't seen this ...
PC Perspective has put up a little article on Alienwares Dual PCI express graphics system. Including a little video of the system in action.
Alienware's Dual PCI-E Graphics System Uncovered
PC Perspective has put up a little article on Alienwares Dual PCI express graphics system. Including a little video of the system in action.
Alienware's Dual PCI-E Graphics System Uncovered
My friend was at E3 and took some high-res photos. The camera did some evil JPG compression though, but they are still decent. The top photo I haven't seen before. Apparently the Alienware people were using 3dmark2003 to demo how the two cards could render the same scene across two cards/monitors....they also had a system doing it normal on one screen.
He said there was no apparent loss of sync or other visual issues. The Alienware rep said it was possible change the load on the cards....like 80% on one, 20% on the other....I don't really understand the potential of this but it is interesting.
In the bottom image with the cards, the wires were there so they could unplug the card and disable half of the rendering. Obviously just for show at E3.
He said there was no apparent loss of sync or other visual issues. The Alienware rep said it was possible change the load on the cards....like 80% on one, 20% on the other....I don't really understand the potential of this but it is interesting.
In the bottom image with the cards, the wires were there so they could unplug the card and disable half of the rendering. Obviously just for show at E3.
Nick Spolec
Newcomer
Basic said:Yes, do you think that would be a bottleneck?
I think two cards could share one 16x PCIex stream just fine. Video cards barely fully utilize the bandwidth of AGP 4x.
"Unplug" in what way?
Why would they want to disable half of the rendering?
If they want to show how the load is distributed, then just do it in the way it looks like they're doing it in the first image. Send the output from the two cards to one monitor each instead of to the extra video mixing card.
One reason to have a special wire to the two cards is to keep their screen refresh in perfect sync. That's what I would have guessed that the blue+red wire was.
The reason to split the screen top/bottom is most likely that it's much easier to merge them that way. With a horizontal split, it's possible to switch source while doing the horizontal retrace. With a vertical split, there's zero time to do the switch.
If they had used DVI instead, they could have done a perfect vertical split, or even a checkerboard. But it would need far more complex circuitry. Decoding two DVI streams, merging them, and encode it again, instead of just an analog switch.
The horizontal switch doesn't have to be a problem. They could do dynamic load detection, and move the split up/down until both cards have equal load.
Seems like a sound theory. I suspect they will implement load balancing as you say. There is still a vertical blank time so to say there's zero time to switch with a vertical split is a little bit of an exaggeration. Although this time is much less than the sum of the horizontal refreshes for half the screen.Basic said:
By a vertical split I mean that the spliting line is vertical. Thus one card would render the left part, and the other card render the right part.
In that case there's zero time to switch from left card to right card. Switching back from right to left is easier since it can be done at the horizontal retrace time.
It could be done even with zero time for the switch, but it's harder to get it right than splitting top/bottom.
In that case there's zero time to switch from left card to right card. Switching back from right to left is easier since it can be done at the horizontal retrace time.
It could be done even with zero time for the switch, but it's harder to get it right than splitting top/bottom.
Right. I understood correctly. I was just nitpicking and saying that there is a vertical blank time where the monitor moves its guns from the bottom right of the screen to the top left. It's not much time, but a little. Video streams can transmit closed captioning or other information during this time so switching could occur here. It just occured to me that this vertical blanking tiime might be artificial for LCDs since they don't refresh in the same manner as CRTs.Basic said:
According to alienware it "analyses" the scene and splits the load in an attempt to balance it.
So how would such a load-balancing system re-merge the two portions of the screen to form 1 image in hardware? Seems like it would maximize the performance increase while introducing significant complexity into the video-merging hardware. Or would it be as simple for the driver to send the ratio mixture to the hardware-merger in terms of scan-lines? eg: for 1600x1200 resolution and a 75%:25% mix, it would send a "900" to indicate card-2 image starts at 75% down the screen...
I guess that what may happen is it will analyse the difference in time the board took to render their previous portion of the frame. So, on the first frame, it would start up at a default split (say, 50/50) and then it would see what the difference in time was for each board to render its frame portion and alter the split on the next frame (and it might possibly even continue to do that to fine hone it over a number of frames, but that would mean if the scene content distribution suddenly change it may take a number of frames to balance again) - this way the split can effectively be communicated to all the devices responsible for generating the final full frame.
Not sure if it's been mentioned/asked in here before, but wouldn't this method of splitting any rendering require vsync to be enabled? Or at least prevent the system from moving on to the next frame until all cards are done processing the currently requested frame?
Similar threads
