SLI with 2 different brand.

[pansertjald]

Actually no, SLI still adjusts the cards to run on the same speeds when in use, when not in use it can use separate frequencies (say compute tasks).
But if you're gaming your frequency and vram speed will be adjusted to the lowest denominator.
Otherwise you will lose synchronicity between cards and frame generation, causing even more micro-stutter.

As far as VRAM total amount goes, that's because they use AFR (Alternate Frame Rendering) to accomplish what they have to do.
DX12 and Vulkan can actually change this as they use a different method and will be able to pool video card resources.

This is still in development but will be made available to everyone who has DX12/Vulkan compatible card.

Thats true, but after 2009 the highest card downscales to the lowest cards GPU boost RAM frequencies and not to the standart RAM frequencies like before 2009

So if the lowest card has a high GPU boost, you still gain a good speed on the downscaled card. But i would still stay the hell away from SLI. Never had anything good come out of it

[Evildeffy]

Thats true, but after 2009 the highest card downscales to the lowest cards GPU boost RAM frequencies and not to the standart RAM frequencies like before 2009

So if the lowest card has a high GPU boost, you still gain a good speed on the downscaled card. But i would still stay the hell away from SLI. Never had anything good come out of it

There is a reason why I said in my first post:

The core and RAM frequencies will be adjusted to the lowest speed card.

That said ... SLI/X-Fire is a hassle ... but when DX12/Vulkan games are built up from the ground and include their mGPU capabilities then things will likely be better.
Until such time I recommend just 1 powerful card instead of SLI/X-Fire.

[dadev]

That said ... SLI/X-Fire is a hassle ... but when DX12/Vulkan games are built up from the ground and include their mGPU capabilities then things will likely be better.

I think there's a sizable gap between the expectation and what is achievable right now.

First, to get this out of the way, currently there's no mGPU support in Vulkan. Now this is a broad statement, and what it actually means is that there's no mechanism that allows direct communication between gpus.
It doesn't mean that you can't create work on 2 gpus in parallel, because you can. You can also transfer data through cpu memory, it's reasonable or crap depending on hardware and implementation. You still can't have shared semaphores, and this really sucks. Synchronizing through cpu introduces nontrivial latency, so unless one gpu does completely unrelated work (like one does normal graphics, the other does global illumination or physics) you can't really make it work well enough. In short, it'll hardly double your frame rate.
It is planned for the future though. As far as I know, Vulkan was basically rushed without mGPU support in order to not be too late to the market (like OpenGL usually was), this might turn out as a good decision.

In DX12 the situation is completely different. There're are not one, but two mGPU modes.
One is SLI/CF, but without the middle man. And in fact you need to have SLI/CF enabled in the respective control panel for this to work. Control panel alone is not enough of course, and you need a full mGPU support in the engine for it. You create a single interface and address gpus with masks. This is the performant mGPU mode, as you get to fully control all linked nodes and decide upon synchronizations between them. Getting x2 frame rate (or close to it) from this mode, with traditional AFR, is not difficult as long as you can keep the frame time on cpu low enough.
However, this mode is also subject to exactly the same limitations as SLI/CF simply because it requires it enabled. Just to note, this is almost nothing like SLI/CF in DX11 for which the driver had to do the actual implementation. In this case implementation is by the engine.
The other DX12 mGPU mode is the so called multi adapter. In this case, it's like Vulkan (you create multiple adapters and work with each gpu independently), however DX12 also allows sharing resources and fences (this is for synchronization, in case you don't know the terminology, like Vulkan's semaphore) between gpus. In essence this allows to transfer data and events between gpus without full intervention of Windows. Partial intervention is still there though, and this is what sets apart the "linked node" mode and the "multi adapter" mode on the performance side. Implementation by the engine is radically different, because in multi adapter you don't use masks, but each adapter gets a dedicated interface.

tldr. this is not 100% up to game engines. vulkan is not there yet. dx12 is, but there are "buts" if you deviate from the SLI/CF model.

[Evildeffy]

I think there's a sizable gap between the expectation and what is achievable right now.

First, to get this out of the way, currently there's no mGPU support in Vulkan. Now this is a broad statement, and what it actually means is that there's no mechanism that allows direct communication between gpus.
It doesn't mean that you can't create work on 2 gpus in parallel, because you can. You can also transfer data through cpu memory, it's reasonable or crap depending on hardware and implementation. You still can't have shared semaphores, and this really sucks. Synchronizing through cpu introduces nontrivial latency, so unless one gpu does completely unrelated work (like one does normal graphics, the other does global illumination or physics) you can't really make it work well enough. In short, it'll hardly double your frame rate.
It is planned for the future though. As far as I know, Vulkan was basically rushed without mGPU support in order to not be too late to the market (like OpenGL usually was), this might turn out as a good decision.

In DX12 the situation is completely different. There're are not one, but two mGPU modes.
One is SLI/CF, but without the middle man. And in fact you need to have SLI/CF enabled in the respective control panel for this to work. Control panel alone is not enough of course, and you need a full mGPU support in the engine for it. You create a single interface and address gpus with masks. This is the performant mGPU mode, as you get to fully control all linked nodes and decide upon synchronizations between them. Getting x2 frame rate (or close to it) from this mode, with traditional AFR, is not difficult as long as you can keep the frame time on cpu low enough.
However, this mode is also subject to exactly the same limitations as SLI/CF simply because it requires it enabled. Just to note, this is almost nothing like SLI/CF in DX11 for which the driver had to do the actual implementation. In this case implementation is by the engine.
The other DX12 mGPU mode is the so called multi adapter. In this case, it's like Vulkan (you create multiple adapters and work with each gpu independently), however DX12 also allows sharing resources and fences (this is for synchronization, in case you don't know the terminology, like Vulkan's semaphore) between gpus. In essence this allows to transfer data and events between gpus without full intervention of Windows. Partial intervention is still there though, and this is what sets apart the "linked node" mode and the "multi adapter" mode on the performance side. Implementation by the engine is radically different, because in multi adapter you don't use masks, but each adapter gets a dedicated interface.

tldr. this is not 100% up to game engines. vulkan is not there yet. dx12 is, but there are "buts" if you deviate from the SLI/CF model.

There are always caveats but those SHOULD be temporary when both DX12 and Vulkan get into full swing.
I have no doubt that traditional X-Fire/SLI will be given way to implementations of both DX12/Vulkan at some point but that point isn't here yet.

Which is why I prefer single powerful cards.
Having said that ... AMD mentioned something about creating a new Multi-GPU technology during their first Polaris presentation and it's been hush-hush ever since.

Perhaps they found/are researching a way to have 2 GPUs work as 1 large GPU with hardware synch instead of driver synch.
This was rumoured a while back and it could honestly turn the tide in mGPU tech if they could make this happen.

That said, having had extensive experience with both SLI and X-Fire ... I will not touch mGPU again until it has matured properly in the API's or as previously mentioned having a hardware-based middleman combining the GPUs as 1 big GPU.

This is already possible for a long time for CPUs and whilst GPUs are inherently more complex the principle is the same.

Who knows what's in store really, when AMD released Eyefinitiy (gimmick yes) it came as a complete surprise because they kept their mouth shut as to it's development and had nVidia panicking when it did... they could be up to the same shenanigans.