nDisplay: -dx12 -quad_buffer_stereo outputs mono when the display is a multi-GPU NVIDIA Mosaic (works on DX11, and on a single-GPU surface with the same build)

General Issues and Bug Reporting (Unreal Engine)
, , , ,
1

Summary

On a machine whose display output is an NVIDIA Mosaic spanning two GPUs, running an nDisplay cluster node with -dx12 -quad_buffer_stereo produces a mono image. Both eyes are rendered - the frame rate halves as expected for stereo - but there is no depth on screen, and no error or warning appears in the log.

Two controlled comparisons narrow this considerably:

Same machine, only the RHI changes. -dx11 -quad_buffer_stereo displays correct stereo on that machine. That is our live production configuration and runs daily - same GPUs, same Mosaic, same driver, same OS, same projectors, same driver stereo mode (On-board DIN connector), 120 Hz active shutter-glasses stereo.

Same engine build, only the display topology changes. The identical build (5.7.3-50162420+++UE5+Release-5.7) produces correct DX12 stereo on a second machine whose output is a single-GPU surface.

WORKING MACHINE - displays correct stereo:
Engine build: 5.7.3-50162420
Output surface: single GPU, 7680x2160
GPU: NVIDIA Quadro RTX 6000 (Turing)
Driver: 596.72 and 582.53 (both tested, both stereo)
OS: Windows 11 25H2
Cluster: 1 node and 2 nodes (both tested, both stereo)
RHI / feature level: D3D12 SM6

FAILING MACHINE - displays mono:
Engine build: 5.7.3-50162420 (identical)
Output surface: NVIDIA Mosaic spanning 2 GPUs, 6467x3830
GPU: NVIDIA RTX PRO 6000 Blackwell
Driver: 582.53
OS: Windows 11 24H2
Cluster: 2 nodes
RHI / feature level: D3D12 SM6

So neither factor alone is sufficient - this looks like an interaction between the D3D12 presentation path and this display topology.

Note this is not Unreal’s multi-GPU feature. -MaxGPUCount is not passed, so the engine renders on a single GPU in both cases. The two-GPU aspect is entirely in the Mosaic / scan-out layer, which the engine never sees.

Questions we would like answered: (1) both RHIs request a structurally identical stereo swapchain and the engine hands Present a correct 2-slice buffer on D3D12, yet only the D3D11 output actually displays as stereo on this machine - does the D3D12 present path need anything additional that D3D11 receives implicitly, or is this entirely a driver responsibility? (2) Is nDisplay quad-buffer stereo on D3D12 known to work with a Mosaic surface spanning multiple GPUs - has that been validated? (3) The same symptom has been reported since 5.0.3 in nDisplay stereoscopic rendering dx12 with no response - is there a known issue tracked internally, or should this go through UDN?

What Type of Bug are you experiencing?

Rendering (Graphics / Niagara)

Steps to Reproduce

  1. Configure an NVIDIA Mosaic display surface that spans two GPUs, with quad-buffer stereo enabled in the driver. Our stereo display mode is On-board DIN connector; the venue runs 120 Hz active shutter-glasses stereo.
  2. Launch an nDisplay cluster node against that surface: .uproject -game -dc_cluster -dc_cfg=.ndisplay -dc_node= -dx12 -quad_buffer_stereo -windowed with a borderless window covering the Mosaic surface, ray tracing disabled, and no -MaxGPUCount (so the engine renders on a single GPU).
  3. View the output through the active stereo glasses.
    Relaunch identically but with -dx11 in place of -dx12, changing nothing else, and compare.

Expected Result

Stereo output under -dx12 -quad_buffer_stereo - as produced by -dx11 -quad_buffer_stereo on the same machine and display, and as produced by -dx12 -quad_buffer_stereo on a machine with a single-GPU output surface running the identical engine build.

Observed Result

DX12: mono. Both eyes are rendered - the frame rate halves as expected for stereo - but the displayed image has no depth. No error or warning is logged.

DX11, same machine, same session, only the flag changed: correct stereo.

Further observations from our investigation:

  • Not the driver version. We installed the failing machine’s driver (582.53) on the working machine. Still stereo.
  • Not the cluster size. A 2-node cluster on the working machine still gives stereo.
  • Not a swapchain creation failure. The log lines “was not able to create stereo SwapChain” and “Backbuffer does not support stereo rendering.” never appear on either machine - so the stereo swapchain is created and nDisplay sees an array-typed backbuffer.
  • Both RHIs request a structurally identical stereo swapchain - “Stereo = TRUE”, “DXGI_SWAP_EFFECT_FLIP_DISCARD”, “BufferCount = 2” - and Present is a plain “SwapChain1->Present” in both, with nothing stereo-specific.
  • The engine delivers a correct stereo buffer on D3D12. We instrumented nDisplay on a separate workstation to tag the left eye red and the right eye green immediately before their copies into the backbuffer, then read back slice 0 and slice 1 of the real presented swapchain buffer. On D3D12 slice 0 = red and slice 1 = green, identical to the D3D11 path that displays correctly.

The driver stereo configuration on the failing machine is demonstrably correct: the same Mosaic and the same On-board DIN connector stereo mode deliver correct stereo every day under D3D11. This is not a case of stereo being misconfigured in the control panel.

Affects Versions

5.7

Platform(s)

Windows