The documentation at https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-nsight-aftermath-for-gpu-pipeline-debugging-in-unreal-engine states that in order to enable Aftermath you need to set r.GPUCrashDebugging=1. This however causes D3D12_GetDredMode() to return ED3D12DredMode::Full, which enables DRED. And if DRED is enabled, Aftermath initialization in UE::RHICore::Nvidia::Aftermath::InitializeDevice() fails with Result=GFSDK_Aftermath_Result_FAIL_D3DDebugLayerNotCompatible.
As it turns out, following the documentation disables Aftermath rather than enabling it.
I have tested it only on the main p4 branch, I don’t know how it behaves in UE5.6. But even if the logic behind this CVar has changed only on the main branch and the documentation just lags behind, it’s a deceptive move to reverse the meaning of a CVar.
Hi Gabor,
I just tried this on my end and was able to start Aftermath and complete DRED with GPUCrashDebugging enabled in 5.6. However, this fails on our latest internal build, so it is interesting that you pointed this out. I’ll check internally if we already know about this regression. How did you figure out the initialization failed due to enabling full DRED?
Hi Tim,
Yesterday I was convinced it is related to r.GPUCrashDebugging and when I checked the code where is CVarGPUCrashDebugging used before Aftermath initialization, the only place I found was DRED from the following callstack.
UE::RHI::ShouldEnableGPUCrashFeature(IConsoleVariable &, const wchar_t *)
D3D12_GetDredMode()
FD3D12Adapter::CreateRootDevice(bool)
And because Aftermath is not compatible with D3D Debug Layer that’s why I thought that it’s not compatible with DRED either.
Today I’m unable to reproduce the issue. I’m able to launch the editor with both DRED and Aftermath.
Maybe yesterday I caused the issue accidentally by forgetting to disable renderdoc.AutoAttach or -AttachPix, which is understandable that they are not compatible with Aftermath. I’m sorry for drawing the wrong conclusion.
Okay, I see. Something similar happened to me yesterday when I was testing this issue, and since I cannot repro this again today, it sounds like we can just close this case for now unless you find something else. Let me know what you think.
I agree, we can close this. Thank you for the help.
But improving the logging might help prevent similar confusion in the future. For example if the Result is GFSDK_Aftermath_Result_FAIL_D3DDebugLayerNotCompatible then report “A debug layer not compatible with Aftermath has been detected. Make sure to disable Pix, RenderDoc and similar tools.”
That sounds like something we can look into, although we already print the error code, which can be cross-referenced with the source code to quickly get some info about the initialization failure.