<h2>Your assumption is wrong</h2>
<p><a href="https://stackoverflow.com/questions/43811699/opengl-multi-gpu-support">It actually <em>was</em> this way</a>, in fact, things have changed <em>the other direction</em>.</p>
<h2>History</h2>
<p>Currently (<a href="https://en.wikipedia.org/wiki/NVLink" rel="nofollow noreferrer">pre nvidia link consumer graphics</a>) 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 <a href="https://en.wikipedia.org/wiki/Scalable_Link_Interface" rel="nofollow noreferrer">HB version</a>, it is only meant to be a framebuffer copier.   You otherwise had to send the same information across all GPUs via PCIE.</p>
<blockquote>
<p>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. <em><strong>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</strong></em>. 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.</p>
</blockquote>
<p>(emphasis mine).</p>
<p>But you didn't typically actually treat this set up as one GPU in the way <em>you</em> want in old times because if you wanted to <em>cooporate</em> work loads instead of merely <em>splitting workloads</em> that required GPU-&gt;GPU communication, which necessarily had to be done VIA pcie, which would be very slow.</p>
<p>At least for opengl, SLI/Xfire rendering was handled via Driver treating the two as the same. <a href="https://stackoverflow.com/a/43812678/2036035">https://stackoverflow.com/a/43812678/2036035</a> You didn't have the <em>option</em> of treating them as separate if they were linked.</p>
<h2>Modern</h2>
<p><a href="https://arstechnica.com/gadgets/2018/03/vulkan-1-1-adds-multi-gpu-directx-compatibility-as-khronos-looks-to-the-future/" rel="nofollow noreferrer">Today however</a>, vulkan and DX12 essentially give <strong>more control</strong>.</p>
<blockquote>
<p>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. <em><strong>Unlike SLI and Crossfire of old, where the task of divvying up the rendering between GPUs was largely handled by the driver</strong></em>, this support gives control to the developer. With the addition, developers can create &quot;device groups&quot; that aggregate multiple physical GPUs into a single virtual device and choose how work is dispatched to the different physical GPUs. <em><strong>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</strong></em>.</p>
</blockquote>
<p>(emphasis mine)</p>
<p>Today <em>you can</em> look at these GPUs separately.</p>

CC BY-SA 4.0
2018-08-22T15:01:08.370Z
So, >>very<< geneally speaking, today, we are treating multiple GPUs the same way as we are treating miltiple CPU cores?
Karlovsky120
CC BY-SA 4.0
2018-08-22T15:07:44.930Z
@Karlovsky120 Yes, that's pretty much exactly it in the vulkan API, you can't address individual cores on your GPU (not even in the actual assembly your GPU uses) , you essentially treat them as separate "cores" in and of their own right, and can do explicit memory synchronization, dispatch different workloads etc.., **or** you can treat them as the same object (with device groups).  In fact in Vulkan, even one GPU is essentially treated as a separate core.
Krupip
CC BY-SA 4.0
2018-08-22T14:47:29.330Z
2018-08-22T14:47:29.330Z
2020-06-18T08:32:12.800Z
Krupip
<p>I hope I'm not off topic here, but this seemed like a good place to ask something like this.</p>

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

<p>I never could understand why were the developers ones that needed to support it.</p>

<p>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.</p>

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

<p>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.</p>

<p>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?</p>

<p>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.</p>

<p>What gives?</p>

<gpu><driver>
Why isn't multi-gpu handled by the driver?
Karlovsky120
# Why isn't multi-gpu handled by the driver?

(Asked by: username_0 on 2018-08-22)

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?

**Tags:** gpu, driver


---

## 1 answers

### Answer by username_1 on 2018-08-22. Score: 3 | Accepted answer

## Your assumption is wrong

[It actually *was* this way](https://stackoverflow.com/questions/43811699/opengl-multi-gpu-support), in fact, things have changed *the other direction*.

## History

Currently ([pre nvidia link consumer graphics](https://en.wikipedia.org/wiki/NVLink)) 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](https://en.wikipedia.org/wiki/Scalable_Link_Interface), 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](https://arstechnica.com/gadgets/2018/03/vulkan-1-1-adds-multi-gpu-directx-compatibility-as-khronos-looks-to-the-future/), 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.

> **Comments:**
> **username_0**: So, >>very<< geneally speaking, today, we are treating multiple GPUs the same way as we are treating miltiple CPU cores?  
> **username_1**: @username_0 Yes, that's pretty much exactly it in the vulkan API, you can't address individual cores on your GPU (not even in the actual assembly your GPU uses) , you essentially treat them as separate "cores" in and of their own right, and can do explicit memory synchronization, dispatch different workloads etc.., **or** you can treat them as the same object (with device groups).  In fact in Vulkan, even one GPU is essentially treated as a separate core.  

---

