It looks like you're new here. If you want to get involved, click one of these buttons!
The immediate impetus for this post was this article:
You can read it if you like, but the article gave the impression that the author had never done graphics programming and a lot of what he said is just guessing. So most of what I'm going to say isn't from that article.
The article claims that DirectX 12 will allow games to use both AMD and Nvidia cards together to share the rendering duties. I not only find this highly plausible, but would be surprised if isn't true. And I expect the same for OpenGL 5.
There is, in fact, already an API out there that lets you use AMD and Nvidia video cards together in the same program to do stuff. Intel graphics, too. It's called OpenCL. But it's not built for graphics. It is, however, pretty obvious how to bring the same functionality from OpenCL into OpenGL, which is why I'd be surprised if it doesn't happen with OpenGL 5.
The way that OpenGL 4.x works today is that you have some primary GPU and you tell it, buffer this texture, buffer this vertex array, compile this shader, buffer this uniform, run this draw call, etc. DirectX does basically the same thing. SLI and CrossFire are handled purely by driver magic, where the video drivers take the API calls and decide which GPU it needs to be passed to--or in some cases, both.
The way that OpenCL works, in contrast, is that you can ask for all of the OpenCL-compliant devices in the machine. In a consumer rig, this would typically mean the CPU and whatever GPUs you have--both discrete and integrated if you have both. And then you can tell it, run this API command on this device, run that API command on that device, and so forth. OpenCL lacks the graphics-specific API commands of OpenGL, so if you want to use it for graphics, you're going to have to roll your own on a lot of things. Some things such as hardware tessellation are completely unavailable.
So what happens if you mix the OpenCL queue system that lets you send different API calls to different devices with the graphics-specific features of OpenGL? That's what I expect OpenGL 5 to demonstrate, and it sounds like DirectX 12 will, too.
Does this mean that adding a second GPU will double your performance? No, not at all. If you have two identical GPUs, it's not automatic that the new options of DirectX 12 and/or OpenGL 5 will actually give you better ways to use both GPUs than traditional SLI/CrossFire. But it would give you a lot of options to take advantage of two different GPUs in a system, such as the integrated graphics that came with the CPU as well as a discrete card. Or, if it becomes popular, the newer video card you just bought, together with the older card it replaced.
However, this is going to be very game-dependent. If a game developer doesn't explicitly implement ways to take advantage of multiple GPUs, then the game won't take advantage of multiple GPUs at all. This isn't something that can be done well by driver magic. Remember the Lucid Hydra, that let you have two different GPUs in the same machine and use them together to render a game? Sometimes using both GPUs was slower than just using one.
But there are a lot of things that a game developer could implement. Probably the simplest is having one GPU render the game while the other does something else. Some games have already done this with physics, mainly using Nvidia's PhysX. That required both GPUs to be Nvidia, however, which basically killed it. It might have had a chance if you could do physics on the integrated graphics while rendering the game on a discrete card, but Nvidia has no x86 license, and hence no high-performance integrated graphics for desktops or laptops.
In the game I've been working on, I've long pondered using OpenCL to render textures when they're embarrassingly parallel. That, like GPU physics, could be done today, though. It doesn't require new APIs. And most (meaning, nearly all) games load textures from storage rather than generating them from formulas.
So how would two GPUs work together to render a frame? One alternative is split frame rendering. One GPU handles the left side of the screen, while the other does the right. Once they've both rendered their portion, you copy one GPU's framebuffer to the other and display it.
This notably wouldn't require comparably powered GPUs. The player could be allowed to mark where the line between the GPUs would be. If you have, for example, a GeForce GTX 980 and also a GeForce GTX 580, you could have the former render 70% of the screen and the latter 30%.
Split frame rendering isn't new, though--and AMD and Nvidia moved away from it as the way to implement CrossFire and SLI for good reasons. A lot of the work up to rasterization would have to be duplicated on both GPUs. An intelligent programmer designing his game for this could filter a lot of objects as being off of the portion of the screen that that GPU will render, but anything near or on the boundary line would have to be sent to both. This can't be done purely by driver magic, which is why it isn't how CrossFire or SLI work today. Split frame rendering would also disable any features handled by driver magic that aren't common to both of the cards. If the screen is split in half and the two halves do anti-aliasing differently, it's likely going to look bad.
And while the article is hopeful that this will free up video memory, split screen rendering doesn't help much. All of the textures and vertex data would have to be on both cards, as the camera can rotate quickly. If you try to only buffer things for one side or the other, you're probably going to get hitching when it tries to switch sides.
Another approach would be to have one GPU handle the near objects, while the other handles the far objects. This would allow for a lot of texture and vertex data to only be on one video card, which does free up video memory. It doesn't necessarily free up all that much on one of the cards, however, as the "far" card has to have nearly everything buffered. But it could be useful if you know that one card is going to have a lot more video memory than the other.
This approach has drawbacks of its own, though. Merging the frame buffers necessarily means that one GPU has to send its entire framebuffer for the entire screen to the other, not just part of it. Furthermore, the depth buffer needs to be sent, too. You could compress the depth buffer to a single bit per pixel before sending it, as the "back" GPU just needs to know if the "front" one drew anything at all, but compressing and decompressing the data is a performance hit, too. Furthermore, this would make it very hard to balance the load between the GPUs.
Yet another approach would be to pick objects and arbitrarily assign them to GPUs, so that each GPU gets some fixed percentage of things to draw. This would balance the load between GPUs pretty well, and once both have rendered their frame, you have to send the entire frame buffer to the other GPU for a final draw call to merge them. This would allow allow most texture and vertex data to only be present on one GPU, as the same GPU could render the same objects every frame.
But this would require sending the entire depth buffer, in addition to the frame buffer, while making it impossible to compress either. That's a lot of PCI Express bandwidth. Furthermore, if there are post-processing effects, you'd have to wait for both GPUs to finish the "main" part of the frame, then one sends its data to the other, and one does post-processing completely on its own. This would break a lot of anti-aliasing methods, too; post-processing forms of anti-aliasing would still be available, but one GPU would have to handle it entirely on its own.
The final approach that I'd like to mention is having one GPU render the "main" frame, while the other does only post-processing effects. If a game is heavy enough on post-processing effects, this could be a decent balance between the GPUs. Or if a game is 2/3 main rendering and 1/3 post-processing, a stronger GPU could handle one while a weaker one handles the other. This would also allow a lot of stuff done by driver-magic to work even if only one GPU supports it.
However, because you'd effectively have different GPUs working on different frames at the same time, you're going to increase the time it takes to render a frame slightly. Like CrossFire/SLI setups, you'd increase your frame rates, but your experience wouldn't be as good as a single faster card that can provide the higher frame rate all by itself. It would mostly avoid the frame timing problems of CrossFire and SLI, though.
It would also require sending the entire frame buffer from one GPU to the other. Whether the depth buffer would be necessary depends on what you're doing with post-processing.
So game designers are soon going to have a lot of options for how to take advantage of multiple GPUs. Which do I expect games to use? For the most part, none of them. Few games offer graphical features that most users will never be able to take advantage of. And the optimal approach for a multi-GPU rig with two comparable GPUs is very different from the optimal approach where one GPU is much stronger than the other.