nVIDIA's "SLI" solution
- Thread starter 991060
- Start date
trinibwoy said:
I think the overclockers will always find a way.
SLI 6800's will be perfect to run this beast from Apple
30 inches! DVI input, 2560x1600 res.
http://www.apple.com/dk/displays/
With SLI you could run 4 of these screens = 60 inches, 16.4 megapixel, 5120x3200 (oops fixed
). Does a 6800 have the 2d fillrate capabilities to render at these resolutions??
Leto said:trinibwoy said:
I think the overclockers will always find a way.
SLI 6800's will be perfect to run this beast from Apple
image snipped
30 inches! DVI input, 2560x1600 res.
http://www.apple.com/dk/displays/
With SLI you could run 4 of these screens = 60 inches, 16.4 megapixel, 10240x6400.
Does a 6800 have the 2d fillrate capabilities to render at these resolutions??
How do you get 10240x6400?
That would take 16 screens.
The Apple gigantic monitor has a native resolution (or did I get that the wrong way?) of 2560*1600. Anything lower then the native resolution on TFT/LCD monitors isn´t usually a good idea. Could it be that the Mac NV40 GPU´s have a different RAMDAC? Last I checked NV40´s support a maximum of 2048*1536*32.
It's probably the same as other high-res LCDs: dual-(or higher)link allows for a decent refresh rate, whereas driving two 30" displays will probably result in low refresh rates for both blingedy LCDs.[url=http://www.apple.com/displays/digital.html said:
aaronspink
Veteran
nutball said:
Lets see, graphics cards get 2-3x the current CFM of air and 2-3x the fin volume to play with, and it is going to make things worse? What planet are you from.
Aaron Spink
speaking for myself inc.
Scaling the geometry processing using multliple GPU cards shouldn't be too difficult if the cards use screen partitioning (as opposed to scan line interleaving).
If the application's 3d engine uses efficient culling of geometry to the viewport (say using hierarchical bounding volumes) the scaling happens automatically since geometry outside a card's partition is efficiently culled before being processed.
If it was felt important to scale the geometry processing of applications that didn't bother to efficiently cull geometry it could be handled by having each card deterministically process half the vertices. A card would send any processed vertices it processed in the other card's viewport to the other card for rendering. As an possible optimization, you could minimize communications traffic by having each card track the vertices that were in its viewport on the last frame and render those first.
If the application's 3d engine uses efficient culling of geometry to the viewport (say using hierarchical bounding volumes) the scaling happens automatically since geometry outside a card's partition is efficiently culled before being processed.
If it was felt important to scale the geometry processing of applications that didn't bother to efficiently cull geometry it could be handled by having each card deterministically process half the vertices. A card would send any processed vertices it processed in the other card's viewport to the other card for rendering. As an possible optimization, you could minimize communications traffic by having each card track the vertices that were in its viewport on the last frame and render those first.
The card in question reportedly supports Dual dual DVI. (!)Leto said:
I remember a discussion we had here that about bandwidth not too long ago, where some assumed that we would be satisfied with 1600x1200 for the foreseeable future. Doesn't look that way, does it.
Seriously, if Microsoft ever get their asses in gear and produces a GUI that is resolution independent, the resolution limits can lie very much further out. Screens have crept from 72 dpi to 100 dpi, but that is not a limitation of the display technology per se - it can reach MUCH higher resolutions and it would benefit type greatly, in addition to being generally useful. The incredibly restrictive DVI interface has to go though.
BTW, in my opinion screen partitioning might prove to be a more efficient way of distributing processing across multiple pipelines on a single card as the number of pipelines continue to grow and the triangle sizes continue to shrink.
It allows large numbers of vertices and pixels to be processed independently in parallel without potential frame buffer or resource conflicts.
It allows large numbers of vertices and pixels to be processed independently in parallel without potential frame buffer or resource conflicts.
Similar threads
