Does this mean multicard GPU configurations will now become something ordinary as games will support it natively without the stupid profiles and also with better scaling? Because that would be nice and maybe the first time I'll have 2 cards in my system because of it...
No, it wouldn't change that much at all.
Since there is so much confusion about how multi-GPU works, I'm going to try to explain it.
The changes in Direct3D 12 and Vulkan regarding multi-GPU is the following:
1) Common API instead of native API to enumerate GPUs
2) Support for different queues on different GPUs
This does however
not change the major effort in implementing multi-GPU support in games, which is the design of the queues themselves.
(1) is of course a good change, but it's only a minor front-end change. It
only eliminates the need for the few vendor specific lines to set up multi-GPU. And like with any other common API, the underlying features can be implemented in a number of ways, every programmer knows this. That's how both Direct3D, OpenGL and Vulkan works, they are common interfaces across vastly different hardware, different drivers and operating systems. And since
(1) is a minor front-end change, each vendor is free to implement it as they want. This means Nvidia will continue to use the SLI bridge when the user are using matching GPUs. And since AFR with matched GPUs will continue to be the primary use for multi-GPU, the SLI bridge wouldn't become obsolete anytime soon.
AFR works by creating the next queue while the previous one is still being processed by the previous GPU. Several factors determines the ability to scale with AFR:
- Queue dependencies(internal), sync fences etc. needs to be kept to a minimum or avoided.
- Dependencies across frames. Unfortunately many games utilizes shading techniques requiring data from the previous frame, which is problematic when this data resides on the other GPU.
etc.
So multi-GPU scaling comes down game engine design, and Direct3D 12 doesn't change that.
There is a lot of hype around
(2), which will allow a game to offload some independent tasks to different GPUs. But it's actually not new at all, it's been a core feature for years and it's used by professional OpenGL applications.
(2) does however have a challenge, since transfer of data is still very expensive, the GPUs can basically just transfer a few MB each frame or the performance will be dropping. An even greater challenge is that rendering of dynamic scenes is very hard to divide the rendering itself, so we are left with doing independent tasks on each GPU. In a game that could mean that one GPU is busy with the rendering, while any others are doing particle simulations, physics or anything else that's data independent, but somewhere in the pipeline the results are synchronized and used in the main rendering. This would mean that this kind of multi-GPU will never scale very well, it will actually be limited by the workload of the different queues. If for instance the main rendering is 80% of the workload, you can at maximum offload 20%, even if the second GPU is just as powerful. This is why
(2) is never going to scale as well as AFR, it's harder to implement efficiently and we are going to see even fewer games prioritizing this.
It's a common misconception that Direct3D 12/Vulkan will be able to split any workload across
n (matched or unmatched GPUs) and scale well. That will never happen. Splitting the workload has to be done manually.
