Why isn't multi-gpu handled by the driver?

Question

I hope I'm not off topic here, but this seemed like a good place to ask something like this.

I've been hearing about SLI and Crossfire for a long time and how support for it is lacking.

I never could understand why were the developers ones that needed to support it.

GPUs are immensely parallel things. They have thousands of cores that run same code at the same time (generally speaking). The game will run with same code on a GPU with 100 cores and with 1000 cores, it will just scale itself differently.

I want to know what stopped the GPU companies from dealing with this within the drivers.

Why not have the driver detect two physical GPUs and present them to the system as a one logical GPU? It would then make sure that the workload is evenly distributed, while using the SLI bridge to synchronise and exchange the data across the GPUs as needed.

If this was really that great as it looks to be, I'm sure they'd be doing it that way, but they aren't. My question is, why not, where does this idea fall apart?

Only reason I can think of is that the GPUs can't handle both the communication with the CPU and with each other fast enough to make the whole thing feasible, and in order to do so, architectural changes would be need which would not yield any improvements in single GPU systems, but only multi GPU system, which would be far, far rarer.

What gives?

Answer 1

Your assumption is wrong

It actually was this way, in fact, things have changed the other direction.

History

Currently (pre nvidia link consumer graphics) you've got to copy the memory over from separate GPUs to render in cross fire and SLI, as global memory transfer speeds will slow down scaling, and as far as I can tell it did not work as a general direct memory acessor, with only 2G/s bandwidth even with the HB version, it is only meant to be a framebuffer copier. You otherwise had to send the same information across all GPUs via PCIE.

SLI allows two, three, or four graphics processing units (GPUs) to share the workload when rendering real-time 3D computer graphics. Ideally, identical GPUs are installed on the motherboard that contains enough PCI-Express slots, set up in a master-slave configuration. All graphics cards are given an equal workload to render, but the final output of each card is sent to the master card via a connector called the SLI Bridge. For example, in a two graphics card setup, the master works on the top half of the scene, the slave the bottom half. Once the slave is done, it sends its render to the master to combine into one image before sending it to the monitor.

(emphasis mine).

But you didn't typically actually treat this set up as one GPU in the way you want in old times because if you wanted to cooporate work loads instead of merely splitting workloads that required GPU->GPU communication, which necessarily had to be done VIA pcie, which would be very slow.

At least for opengl, SLI/Xfire rendering was handled via Driver treating the two as the same. https://stackoverflow.com/a/43812678/2036035 You didn't have the option of treating them as separate if they were linked.

Modern

Today however, vulkan and DX12 essentially give more control.

One feature in particular goes a long way toward filling a Vulkan gap relative to Microsoft's API: explicit multi-GPU support, which allows one program to spread its work across multiple GPUs. Unlike SLI and Crossfire of old, where the task of divvying up the rendering between GPUs was largely handled by the driver, this support gives control to the developer. With the addition, developers can create "device groups" that aggregate multiple physical GPUs into a single virtual device and choose how work is dispatched to the different physical GPUs. Resources from one physical GPU can be used by another GPU, different commands can be run on the different GPUs, and one GPU can show rendered images that were created by another GPU.

(emphasis mine)

Today you can look at these GPUs separately.