Application Instrumentation with Event Markers

In its basic form, this works by allowing programmers to insert markers into the GPU pipeline, which can be read post-TDR, to determine what work item the GPU was processing at the point of failure. Nsight Aftermath also includes a facility to query the current device state, much like the conventional graphics APIs, but reporting a finer grained reason.

One of the key principles of Nsight Aftermath is for the marker insertion to be as unobtrusive as possible, avoiding situations common with other similar debuggers. When the associated performance cost changes timing enough to make a bug repro vanish, you can have what is often called a “Heisenbug.” Aftermath avoids this problem by using a very light-weight event marker design.

Nevertheless, there is still considerable performance overhead associated with event markers and they should be used only for debugging purposes on development or QA systems. Therefore, on some versions of NVIDIA graphics drivers, Aftermath event marker tracking on D3D11 and D3D12 is only available if the Nsight Aftermath GPU Crash Dump Monitor is running on the system. This requirement applies to R495 to R530 drivers for D3D12 and R495+ drivers for D3D11. No Aftermath configuration needs to be made in the Monitor. It serves only as a dongle to ensure Aftermath event markers do not impact application performance on end user systems.

For Vulkan the Aftermath event marker functionality is exposed as a Vulkan extension: NV_device_diagnostic_checkpoints.