The Many Heads Of Hydra
Again, we’ll go into more depth on the Fuzion’s basic board design and BIOS when it comes time to explore the similar MSI Trinergy next week. The real differentiator here is Lucid’s Hydra 200 ASIC, which takes the place of Nvidia’s nForce 200. The Trinergy and Fuzion are both $350 P55-based boards, so what this really boils down to is a choice. Choose SLI/CrossFireX with support for up to 3-way SLI. Or choose the flexibility to mix/match cards/vendors.
When you go the former route, you play by the rules set forth by ATI and Nvidia for achieving a compatible multi-GPU configuration. The means identical GPU models in an SLI setup and GPUs from the same family when you go CrossFire. But you also get the validation those companies put into their established technologies.
Should you choose the latter path instead, you have five possible combinations opened up to you, three of which are exclusive to Lucid’s solution:
| Header Cell - Column 0 | LucidLogix-Exclusive | Example Config |
|---|---|---|
| N-Mode: Identical Nvidia Cards | No | GeForce GTX 285 / GeForce GTX 285 |
| N-Mode: Non-Identical Nvidia Cards | Yes | GeForce GTX 285 / GeForce GTX 260 |
| A-Mode: Identical ATI Cards | No | Radeon HD 5870 / Radeon HD 5870 |
| A-Mode: Non-Identical ATI Cards | Yes | Radeon HD 5870 / Radeon HD 4870 |
| X-Mode: Multi-Vendor | Yes | Radeon HD 5870 / GeForce GTX 285 |
So, we have a trio of capabilities you’ve never seen before: N-mode using non-identical Nvidia cards, A-mode using non-identical ATI cards, and X-mode leveraging multi-vendor interoperability, which was a “demo” mode previously, but was recently upgraded to a production status with Lucid’s most recent driver drop.
Achieving The Unachievable
The specifics of how Lucid is able to get GPUs from the same vendor (but with different performance profiles) and GPUs from different vendors working cooperatively is tightly related to the company’s load-balancing algorithms.
There’s a reason why ATI and Nvidia want you to put cards with common performance attributes together.
ATI supports three different modes for displaying your favorite game across a pair of graphics cards: alternate frame rendering, whereby each GPU handles odd or even frames, supertiling mode, which divides the screen into a 32x32 pixel checkerboard of sections rendered alternately by each GPU, and scissor mode, where the screen is split, with one part rendered by GPU 1 and the other rendered by GPU2. ATI’s own product page admits that scissor mode is not as efficient as the company’s other techniques, but works best in OpenGL-based titles. Of course, the supertiling and scissor modes are largely technical additions to CrossFire, since ATI’s own list of best practices suggests programming with alternate frame rendering in mind. Thus, most of the apps you’d run in CrossFire are optimized for this mode anyway.
Nvidia supports two performance modes: split-frame rendering and alternate frame rendering. Split-frame works like ATI’s scissor mode, dividing the frame up to split its workload up between GPUs. And, as with ATI’s implementation, this isn’t as efficient as AFR. Alternate frame rendering functions similarly as well, assigning one card to even frames and the other to odd.
The problem with split-frame/scissor mode is that, while they help alleviate the pixel processing workload, each GPU still has to store the entire frame in its memory, so geometry and (arguably more important) memory bandwidth aren’t helped at all. Meanwhile, tiling is negatively affected by inter-frame dependencies, such as render targets being used in the following frame.
As a result, AFR is most often used. It makes sense, then, that you’d want GPUs with identical performance working on one frame after another. And even when you have this, one frame might take milliseconds longer to render than the one before, resulting in an artifact of multi-GPU configurations referred to as micro-stuttering. Though less perceptible at high speeds, it’s inevitable that I do a story covering CrossFire or SLI and get asked if the hardware in question exhibits signs of micro-stuttering. We’ll go into more depth on this shortly…
…the point is that Lucid did its homework in setting forth Hydra’s minimum requirements and determined it needed to: allow non-identical GPUs to work in the same system, facilitate scalability with more than one card installed, and eliminate the need for over-the-top connectors between cards. And since the company so clearly defines its goals, it becomes particularly easy for us to evaluate where it stands in relation to them today.
According to Lucid, its Hydra engine is able to intercept DirectX/OpenGL calls and, rather than use something like AFR to divvy up the workload, break each frame into “tasks.” A task isn’t necessarily a screen ratio or series of uniform tiles, but could instead be a 3D object, for example—it’s up to the engine to determine which rendering technique to use. Those tasks are then distributed to the installed GPUs (currently limited to two) through the vendor’s driver (which isn’t even aware of Lucid’s software running in front of it, since Hydra employs the standard Device Driver Interface in Windows 7). The completed tasks are returned to what Lucid calls its interop layer, where the frame is composited and sent to the GPU with an attached display.
In order to make this process dynamic—and by that I mean capable of supporting dissimilar GPUs—the Hydra employs a feedback mechanism that evaluates the performance of installed graphics hardware in real-time and load balances accordingly. Thus, in theory, Lucid’s technology circumvents the micro-stuttering issues of alternate frame rendering and resolves the inter-frame dependencies that penalize split-frame rendering.
