New Multi-GPU Technology With No Strings Attached 179
Vigile writes "Multi-GPU technology from both NVIDIA and ATI has long been dependent on many factors including specific motherboard chipsets and forcing gamers to buy similar GPUs within a single generation. A new company called Lucid Logix is showing off a product that could potentially allow vastly different GPUs to work in tandem while still promising near-linear scaling on up to four chips. The HYDRA Engine is dedicated silicon that dissects DirectX and OpenGL calls and modifies them directly to be distributed among the available graphics processors. That means the aging GeForce 6800 GT card in your closet might be useful once again and the future of one motherboard supporting both AMD and NVIDIA multi-GPU configurations could be very near."
AMD and NVIDIA?? (Score:2, Interesting)
My god... (Score:4, Interesting)
I mean, if one GPU is good and two GPUs are better, does that mean 5 are fantastic?
I used to have a Radeon 1950 Pro in my current system, which is nowhere near the top of the scale in video cards (in fact, it's probably below even average). It was so loud and literally doubled the number of watts my system took while running (measured by Kill-a-Watt). I took it out and now just use the integrated Intel graphics adapter. Man, that was fast enough for me but I don't play games very often.
Re:Time to make them imcompatible! (Score:5, Interesting)
Don't you mean Wierd(er).
The reason NVidia requires such symetrical cards isn't just because of speed and frame buffer synchronization but also because different cards render different scenes slightly differently. This is the reason why OpenGL rendering isn't used very often in post production. You can't have two frames come back to you with slightly different gammas, whitepoints, blending algorithms etc etc.
I'm actually very very curious how they intend to resolve every potential source of image inconsistancy between frame buffers. It seems like it would have to almost use the 3D Cards abstractly as a sort of CPU accelleration unit not an actual FrameBuffer generator.
Re:Latency. (Score:1, Interesting)
So reaction times are about 150ms, but if you know in advance, you can hit 17ms?
That's some interesting stuff.
As far as rhythm games go, I make my living as a musician. Most instruments.
I wonder if I have got into the habit of intending physical actions in advance, so reaction time is less important than latency.
In that article they mention frame jitter as well, which I think is the thing that bothers me most. My usual instruments don't do that.
Re:Latency. (Score:3, Interesting)
Re:Interesting (Score:3, Interesting)
I gave TFA a quick perusal
FYI, this is a very common mistake in English, and loathe though I am to be a vocabulary Nazi, I think pointing it out here might benefit other Slashdot readers:
The verb "to peruse" means to read thoroughly and slowly. It does not mean "to skim" -- quite the opposite!
(Unfortunately, it seems that even the OED is giving up this fight, so maybe I should too.)
That's it for this post. Cheers!
Re:Latency. (Score:3, Interesting)
Got an NVidia card? Go into the NVidia control panel, "Manage 3D Settings", "Maximum pre-rendered Frames", and set it to 0. I'm sure you can do something very similar with an ATI card.
Of course, I have a feeling that it's purely psychological what you're experiencing. With a modern computer (and I'm talking about one with more than 133 MHz) the "Windows" latency is below the threshold of humans. In modern 3d games, yes, I do hear the gun go off when I click the mouse - if my computer's specs are high enough to actually play the game at 60 FPS. Doom had the exact same problem - if your computer sucked, there was latency on the gun. Have the rose-colored glasses made you forget that?
Comment removed (Score:3, Interesting)
Re:Interesting (Score:3, Interesting)
What about the fact that different cards give different results for texture filtering? Specifically their choice of mip level and anisotropic filtering. Think circle vs square differences.
Hell, some cards implement anti-aliasing differently to others.
Re:quick (Score:3, Interesting)
Like... an optimizing compiler with OpenMP support that'll break down functions suitable for a GPGPU? Then based on some profiling data (both in development and runtime) it would automatically use the most optimized path, in similar vain to Intel's MT optimizations for their chips.
Re:Eek. Potentially energy inefficient. (Score:1, Interesting)
I'm still kind of surprised that there hasn't been any lego-style system component designs
are you serious? PCI/PCIe/SATA/eSATA/ISA/VESA I can name hundreds of standards that do just what you say. There are dozens of them out there for the interconnects and power.
The reason there are so many different ones out there is really 2 things. Not invented here, and can not expand the port anymore without burning out older equipment if you plug one in.
For example with PCI there was no reason to change the shape of the connector when they went to PCIe. Yet they did. It was mostly so if you plugged a PCI card into a PCIe slot it wouldnt melt your card and your MB. Could they have designed around that? Probably. But just from a simple it doesnt fit makes a lot of problems 'go away'. You also do not have to drag along legacy issues.
Once you fix yourself into a 'lego' style you buy yourself some short term flexibility at a long term design cost. They even tried this with the ISA slot. They kept making it longer and longer adding in more and more pins. You could take a 8 bit card from the mid 80s and plug it into a mid 90s MB and it would work if you had drivers. The problem was the connector got HUGE. More pins = more money. Sure its an extra 8 bucks but say your making 10k of the things... The flexibility ended up being a kludge ontop of a kludge.
Dont think so? Go look at a MB from the mid 90s. Look for a VESA/ISA mb. 16 bit ISA slot and then a 32bit VESA slot just after it. I sacrificed many knuckles on that bad boy design. They were painful to put in and take out. Snapped a few in my day just because they would get stuck.
http://en.wikipedia.org/wiki/VESA_Local_Bus
http://en.wikipedia.org/wiki/Image:Vlb.jpg
http://en.wikipedia.org/wiki/Image:Vlb_svga.jpg
Lego designs sound good at first. At first they are! Then you want to add something that doesnt fit anymore. That is when the kludges start rolling in.
Re:Interesting (Score:3, Interesting)
An especially troublesome aspect of pairing mis-matched cards: whatever this technology is, it can't use alternate-frame rendering (AFR, where alternating frames are sent to alternating cards).
You can't make AFR work with an unbalanced pair of cards because the fastest framerate you can get is limited to 2x the speed of the slowest card. Let me explain: if you paired a new card (100fps) with one that had 1/2 the speed (50fps), if you had perfect scaling, you could technically get 150fps from the pair. But if they used AFR and took turns rendering one frame at a time, the most you could see from the pair is twice the old card's framerate, or 100fps.
AFR could only give you 150fps in this case if the game engine could tell you the future, and supply a frame for rendering one frame in-advance to the older card. This is simply not possible, and the game engine supplies frames only in real time.
So, this means that you have to use a better method to balance the workload between the two (or more) cards. But this was already attempted - Nvidia offered split-screen rendering for SLI, and for a time ATI offered tiled rendering, but both methods had major compatibility issues (and split-screen rendering was notorious for tearing artifacts). Today, both ATI and Nvidia support AFR as the default rendering mode, and very seldom do they step oiutside this circle.
The fact is, other methods besides AFR have already been considered, but in the end AFR is the method the industry has consistently fallen back on. The only real downside of AFR is you need balanced cards, or it won't give you any benefit. Unfortunately, I'm hesitant to believe that ANY company can come up with a better solution for SLI, even a third-party solutions like these.