<p>In DX12, there is no implicit driver-implemented SLI as there was in DX11. Instead, multiple GPUs are exposed to the application as separate "nodes" within a single DX12 device, and each VRAM resource lives on a single node, specified at creation time. There is no implicit mirroring of resources to both GPUs as in DX11 SLI.</p>

<p>So, the game engine or application has full control and responsibility over how data and work are distributed between the GPUs. It's up to the app developers to implement patterns like alternating frames between GPUs, or splitting the frame across GPUs, if they wish. For example, to implement alternating frames, the app would have to allocate all buffers, textures, render targets etc. on both GPUs and populate both of them. Then, when rendering a frame, it would generate a command list for the current GPU using its local copies of all resources. Any inter-GPU transfers needed (for temporal effects, for instance) would also be the app's responsibility.</p>

<p>More information on this topic can be found on <a href="https://docs.microsoft.com/en-us/windows/win32/direct3d12/multi-engine" rel="nofollow noreferrer">this MSDN article on DX12 multi-GPU support</a>.</p>

CC BY-SA 3.0
2016-02-19T02:12:22.923Z
Thanks for the great answer! Would it be possible to allocate texture or geometry data to just individual cards then? The link seemed to indicate that computing could be distributed, which is makes sense, but I'm still confused as to how or if geometry or textures could be split.
aces
CC BY-SA 3.0
2016-02-19T02:20:00.133Z
@aces Yes, you can allocate geometry or textures to just individual cards—you'd just create those resources only on one node. Every time you create a resource, you specify which node to put it on, so you have total control over which GPUs get copies of which resources.
Nathan Reed
CC BY-SA 3.0
2016-02-19T02:22:04.977Z
That makes sense, but would that be feasible in a game? I would think you would have to synchronize all the fragments if you did that somehow.
aces
CC BY-SA 3.0
2016-02-19T02:22:49.977Z
@aces "Synchronize all the fragments"? You've lost me. :)
Nathan Reed
CC BY-SA 3.0
2016-02-19T02:25:53.217Z
Sorry :). In a simple example, if you have one model with a certain texture on one GPU and another model with a different texture on another GPU, they would both need to be rasterized and shaded, so the frame buffer would need to contain both of this information in the end for depth tests. I guess I'm just confused on how that could utilize VRAM stacking.
aces
CC BY-SA 3.0
2016-02-19T02:33:24.280Z
@aces OK, yeah. If you distribute the rendering across GPUs in some way, you have to put the results back together somehow afterward. So in your example, after rendering, you could copy the color & depth buffers from GPU2 back to GPU1, and use GPU1 to composite the two frames together. That would take some extra time, which eats into the time you saved by distributing the rendering in the first place, so it might or might not be an overall perf win depending on circumstances.
Nathan Reed
CC BY-SA 3.0
2016-02-19T02:36:16.770Z
Ah ok, so I guess if the bus latency/bandwidth isn't too bad that could work. Thanks for the clarification!
aces
CC BY-SA 4.0
2016-02-18T03:27:47.513Z
2019-09-14T23:49:50.660Z
2019-09-14T23:49:50.660Z
Nathan Reed
<p>Mainly talking about dual-SLI here for consistency. With past DirectX (and OpenGL) APIs, VRAM was mirrored across graphics cards. With dual-SLI, this was possible by rendering one frame with one graphics card and another frame with another one. There was also a rendering option in which one graphics card would render part of the screen. Unfortunately, there doesn't seem to be much technical information on how VRAM stacking would work. What possible techniques could graphics cards or DirectX 12 be using to allow for this?</p>

<directx12>
How does DirectX 12 SLI VRAM stacking work?
aces
# How does DirectX 12 SLI VRAM stacking work?

(Asked by: username_0 on 2016-02-18)

Mainly talking about dual-SLI here for consistency. With past DirectX (and OpenGL) APIs, VRAM was mirrored across graphics cards. With dual-SLI, this was possible by rendering one frame with one graphics card and another frame with another one. There was also a rendering option in which one graphics card would render part of the screen. Unfortunately, there doesn't seem to be much technical information on how VRAM stacking would work. What possible techniques could graphics cards or DirectX 12 be using to allow for this?

**Tags:** directx12


---

## 1 answers

### Answer by username_1 on 2016-02-18. Score: 7 | Accepted answer

In DX12, there is no implicit driver-implemented SLI as there was in DX11. Instead, multiple GPUs are exposed to the application as separate "nodes" within a single DX12 device, and each VRAM resource lives on a single node, specified at creation time. There is no implicit mirroring of resources to both GPUs as in DX11 SLI.

So, the game engine or application has full control and responsibility over how data and work are distributed between the GPUs. It's up to the app developers to implement patterns like alternating frames between GPUs, or splitting the frame across GPUs, if they wish. For example, to implement alternating frames, the app would have to allocate all buffers, textures, render targets etc. on both GPUs and populate both of them. Then, when rendering a frame, it would generate a command list for the current GPU using its local copies of all resources. Any inter-GPU transfers needed (for temporal effects, for instance) would also be the app's responsibility.

More information on this topic can be found on [this MSDN article on DX12 multi-GPU support](https://docs.microsoft.com/en-us/windows/win32/direct3d12/multi-engine).

> **Comments:**
> **username_0**: Thanks for the great answer! Would it be possible to allocate texture or geometry data to just individual cards then? The link seemed to indicate that computing could be distributed, which is makes sense, but I'm still confused as to how or if geometry or textures could be split.  
> **username_1**: @username_0 Yes, you can allocate geometry or textures to just individual cards—you'd just create those resources only on one node. Every time you create a resource, you specify which node to put it on, so you have total control over which GPUs get copies of which resources.  
> **username_0**: That makes sense, but would that be feasible in a game? I would think you would have to synchronize all the fragments if you did that somehow.  
> **username_1**: @username_0 "Synchronize all the fragments"? You've lost me. :)  
> **username_0**: Sorry :). In a simple example, if you have one model with a certain texture on one GPU and another model with a different texture on another GPU, they would both need to be rasterized and shaded, so the frame buffer would need to contain both of this information in the end for depth tests. I guess I'm just confused on how that could utilize VRAM stacking.  
> **username_1**: @username_0 OK, yeah. If you distribute the rendering across GPUs in some way, you have to put the results back together somehow afterward. So in your example, after rendering, you could copy the color & depth buffers from GPU2 back to GPU1, and use GPU1 to composite the two frames together. That would take some extra time, which eats into the time you saved by distributing the rendering in the first place, so it might or might not be an overall perf win depending on circumstances.  
> **username_0**: Ah ok, so I guess if the bus latency/bandwidth isn't too bad that could work. Thanks for the clarification!  

---

