5
$\begingroup$

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?

$\endgroup$
8
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ 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. $\endgroup$ – aces Feb 19 '16 at 2:12
  • $\begingroup$ @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. $\endgroup$ – Nathan Reed Feb 19 '16 at 2:20
  • $\begingroup$ 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. $\endgroup$ – aces Feb 19 '16 at 2:22
  • $\begingroup$ @aces "Synchronize all the fragments"? You've lost me. :) $\endgroup$ – Nathan Reed Feb 19 '16 at 2:22
  • 3
    $\begingroup$ @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. $\endgroup$ – Nathan Reed Feb 19 '16 at 2:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.