Many D3D12 developers have become accustomed to managing resource state transitions and read/write hazards themselves using the ResourceBarrier API. Prior to D3D12, such details were handled internally by the driver. However, D3D12 command lists cannot provide the same deterministic state tracking as D3D10 and D3D11 device contexts.
In Windows 10 1903, DRED 1.1 provided D3D12 developers with the ability to diagnose device removed events using GPU page fault data and automatic breadcrumbs. As a result, TDR debugging pain has been greatly reduced. Hooray! Unfortunately, developers still struggle to pinpoint which specific GPU workloads triggered the error.
The DirectX Control Panel (DXCpl.exe) has dutifully given developers the ability to configure Direct3D debug settings for nearly two decades. But what started as a simple utility for controlling D3D debug output and driver type selection has struggled to keep up with modern DX12 debugging options.
Microsoft recently announced the release of DRED (Device Removed Extended Data) for D3D12 in the Windows 10 May 2019 Update (previously referred to as the Windows 10 19H1 Preview). Buried in that post is a mention that Microsoft is working on a debugger extension to help simplify post-mortem analysis of DRED.
DRED stands for Device Removed Extended Data. DRED is an evolving set of diagnostic features designed to help identify the cause of unexpected device removal errors, delivering automatic breadcrumbs and GPU-page fault reporting on hardware that supports the necessary features (more about that later).
