Is it common to have more than one ID3D11Device and/or associated immediate ID3D11DeviceContext?

If I am correct a single display subsystem (GPU, video memory, etc.) is completely determined (from a 3D rendering perspective) by a

1. IDXGIAdapter (meta functionality facade);
2. ID3D11Device (resource creation facade);
3. ID3D11DeviceContext (pipeline facade).

So given that you want to use multiple display subsystems, you will have to handle multiple of these interfaces. A concrete example would be a graphics card dedicated to rendering and a separate graphics card dedicated to computation, or combining an integrated and dedicated graphics card. All such cases seem to me quite far fetched to justify support in a majority of games. So moving one abstraction level further downstream, should a game engine even consider multiple display systems (i.e. there is just one ID3D11Device and one immediate ID3D11DeviceContext)?

8 minutes ago, SoldierOfLight said:

so you can actually use multiple GPUs in concert

But do rendering engines exploit this?

15 minutes ago, SoldierOfLight said:

I'm not aware of usage in a shipped engine, but there was a pretty cool demo a while back: https://blogs.msdn.microsoft.com/directx/2015/04/30/directx-12-multiadapter-lighting-up-dormant-silicon-and-making-it-work-for-you/

Thanks looks really impressive!

With AMD Crossfire / NVidia SLI, multiple physical GPUs might masquerade as a single D3D device. With 11, this is transparent magic performed by the driver (or if you want manual control, you can use the NVSDK/AGS extension libraries). With 12, devices now have a NodeMask parameter throughout the API, letting you specify work/resources for each physical GPU in the SLI/Crossfire system. 

17 hours ago, Hodgman said:

With AMD Crossfire / NVidia SLI, multiple physical GPUs might masquerade as a single D3D device. With 11, this is transparent magic performed by the driver (or if you want manual control, you can use the NVSDK/AGS extension libraries). With 12, devices now have a NodeMask parameter throughout the API, letting you specify work/resources for each physical GPU in the SLI/Crossfire system. 

This thus completely breaks the possibility of having singletons for them  (cfr. my other post) (Luckily, 90% of my methods passes these pointers around for use or storing [but not owning]. Though, I wrote some short hands to construct textures, buffers, shaders, etc. via constructors redirecting to the bigger constructors by using the singletons. So the whole I shot in my foot could be stitched )