|
1 | 1 | :pp: {plus}{plus} |
2 | 2 |
|
3 | | -= Tooling: Crash Handling and Minidumps |
| 3 | += Tooling: Crash Handling and GPU Crash Dumps |
4 | 4 |
|
5 | 5 | == Crash Handling in Vulkan Applications |
6 | 6 |
|
7 | | -Even with thorough testing and debugging, crashes can still occur in production environments. When they do, having robust crash handling mechanisms can help you diagnose and fix issues quickly. In this section, we'll explore how to implement crash handling and generate minidumps in Vulkan applications. |
| 7 | +Even with thorough testing and debugging, crashes can still occur in production environments. When they do, having robust crash handling mechanisms can help you diagnose and fix issues quickly. This chapter focuses on practical GPU crash diagnostics (e.g., NVIDIA Nsight Aftermath, AMD Radeon GPU Detective) and clarifies the role and limitations of OS process minidumps, which usually lack GPU state and are rarely sufficient to root-cause graphics/device-lost issues on their own. |
8 | 8 |
|
9 | 9 | === Understanding Crashes in Vulkan Applications |
10 | 10 |
|
@@ -178,11 +178,49 @@ int main() { |
178 | 178 | } |
179 | 179 | ---- |
180 | 180 |
|
| 181 | +=== GPU Crash Diagnostics (Vulkan) |
| 182 | + |
| 183 | +While OS process minidumps capture CPU-side state, GPU crashes (device lost, TDRs, hangs) require GPU-specific crash dumps to be actionable. In practice, you’ll want to integrate vendor tooling that can record GPU execution state around the fault. |
| 184 | + |
| 185 | +==== NVIDIA: Nsight Aftermath (Vulkan) |
| 186 | + |
| 187 | +Overview: |
| 188 | + |
| 189 | +- Collects GPU crash dumps with information about the last executed draw/dispatch, bound pipeline/shaders, markers, and resource identifiers. |
| 190 | +- Works alongside your Vulkan app; you analyze dumps with NVIDIA tools to pinpoint the failing work and shader. |
| 191 | + |
| 192 | +Practical steps: |
| 193 | + |
| 194 | +1. Enable object names and labels |
| 195 | + - Use VK_EXT_debug_utils to name pipelines, shaders, images, buffers, and to insert command buffer labels for major passes and draw/dispatch groups. These names surface in crash reports and greatly aid triage. |
| 196 | +2. Add frame/work markers |
| 197 | + - Insert meaningful labels before/after critical rendering phases. If available on your target, also use vendor checkpoint/marker extensions (e.g., VK_NV_device_diagnostic_checkpoints) to provide fine-grained breadcrumbs. |
| 198 | +3. Build shaders with unique IDs and optional debug info |
| 199 | + - Ensure each pipeline/shader can be correlated (e.g., include a stable hash/UUID in your pipeline cache and application logs). Keep the mapping from IDs to source for analysis. |
| 200 | +4. Initialize and enable GPU crash dumps |
| 201 | + - Integrate the Nsight Aftermath Vulkan SDK per NVIDIA’s documentation. Register a callback to receive crash dump data, write it to disk, and include your marker string table for symbolication. |
| 202 | +5. Handle device loss |
| 203 | + - On VK_ERROR_DEVICE_LOST (or Windows TDR), flush any in-memory marker logs, persist the crash dump, and then terminate cleanly. Attempting to continue rendering is undefined. |
| 204 | + |
| 205 | +References: NVIDIA Nsight Aftermath SDK and documentation. |
| 206 | + |
| 207 | +==== AMD: Radeon GPU Detective (RGD) |
| 208 | + |
| 209 | +- AMD provides tools to capture and analyze GPU crash information on RDNA hardware. Similar principles apply: enable object names, label command buffers, and preserve pipeline/shader identifiers so RGD can point back to your content. |
| 210 | +- See AMD Radeon GPU Detective and related documentation for Vulkan integration and analysis workflows. |
| 211 | + |
| 212 | +==== Vendor-agnostic groundwork that helps all tools |
| 213 | + |
| 214 | +- Name everything via VK_EXT_debug_utils. |
| 215 | +- Insert command buffer labels at meaningful boundaries (frame, pass, material batch, etc.). |
| 216 | +- Persist build/version, driver, Vulkan API/UUID, and pipeline cache UUID in your logs and crash artifacts. |
| 217 | +- Implement robust device lost handling: stop submitting, free/teardown safely, write artifacts, exit. |
| 218 | + |
181 | 219 | === Generating Minidumps |
182 | 220 |
|
183 | | -While basic crash logs are helpful, minidumps provide much more detailed information for diagnosing crashes. A minidump is a file containing a snapshot of the process memory and state at the time of the crash. |
| 221 | +Use OS process minidumps to capture CPU-side call stacks, threads, and memory snapshots at the time of a crash. For graphics issues and device loss, they rarely contain the GPU execution state you need—treat minidumps as a complement to GPU crash dumps, not a replacement. |
184 | 222 |
|
185 | | -Let's implement minidump generation using platform-specific APIs: |
| 223 | +Below is a brief outline for generating minidumps with platform APIs (useful for correlating CPU context with a GPU crash): |
186 | 224 |
|
187 | 225 | [source,cpp] |
188 | 226 | ---- |
@@ -303,7 +341,7 @@ namespace crash_handler { |
303 | 341 |
|
304 | 342 | === Analyzing Minidumps |
305 | 343 |
|
306 | | -Once you have a minidump, you need to analyze it to determine the cause of the crash. Here's how to do this on different platforms: |
| 344 | +Minidumps are best used to understand CPU-side state around a crash (e.g., which thread faulted, call stacks leading to vkQueueSubmit/vkQueuePresent, allocator misuse) and to correlate with a GPU crash dump from vendor tools. Here’s a brief workflow on different platforms: |
307 | 345 |
|
308 | 346 | ==== Windows |
309 | 347 |
|
@@ -467,26 +505,29 @@ namespace crash_handler { |
467 | 505 | } |
468 | 506 | ---- |
469 | 507 |
|
470 | | -=== Best Practices for Crash Handling |
471 | | - |
472 | | -To make the most of your crash handling system: |
473 | | - |
474 | | -1. *Always Include Version Information*: Make sure your crash reports include the application version, Vulkan version, and driver version. |
475 | | - |
476 | | -2. *Collect Relevant State*: Include information about what the application was doing when it crashed (e.g., loading a model, rendering a specific scene). |
477 | | - |
478 | | -3. *Respect User Privacy*: Be transparent about what data you collect and get user consent before uploading crash reports. |
479 | | - |
480 | | -4. *Test Your Crash Handling*: Deliberately trigger crashes in different scenarios to ensure your crash handling system works correctly. |
481 | | - |
482 | | -5. *Implement Graceful Recovery*: When possible, try to recover from non-fatal errors rather than crashing. |
483 | | - |
484 | | -6. *Use Crash Reports to Improve*: Regularly analyze crash reports to identify and fix common issues. |
| 508 | +=== Best Practices for Crash Handling (Vulkan/GPU-focused) |
| 509 | + |
| 510 | +To make crash data actionable for graphics issues, prefer these concrete steps: |
| 511 | + |
| 512 | +1. Name and label aggressively |
| 513 | + - Use VK_EXT_debug_utils to name all objects and insert command buffer labels at pass/material boundaries and before large draw/dispatch batches. Persist a small in-memory ring buffer of recent labels for inclusion in crash artifacts. |
| 514 | +2. Prepare for device loss |
| 515 | + - Implement a central handler for VK_ERROR_DEVICE_LOST. Stop submitting work, flush logs/markers, request vendor GPU crash dump data, and exit. Avoid attempting recovery in the same process unless you have a robust reinitialization path. |
| 516 | +3. Capture GPU crash dumps on supported hardware |
| 517 | + - Integrate NVIDIA Nsight Aftermath and/or AMD RGD depending on your target audience. Ship with crash dumps enabled in development/beta builds; provide a toggle for users. |
| 518 | +4. Make builds symbol-friendly |
| 519 | + - Keep a mapping from pipeline/shader hashes to source/IR/SPIR-V and build IDs. Enable shader debug info where feasible for diagnosis builds. |
| 520 | +5. Record environment info |
| 521 | + - Log driver version, Vulkan version, GPU name/PCI ID, pipeline cache UUID, app build/version, and relevant feature toggles. Include this alongside minidumps and GPU crash dumps. |
| 522 | +6. Reproduce deterministically |
| 523 | + - Provide a way to disable background variability (e.g., async streaming) and to replay a captured sequence of commands/scenes to reproduce the crash locally. |
| 524 | +7. Respect privacy and distribution concerns |
| 525 | + - Clearly document what crash data is collected (minidumps, GPU crash dumps, logs) and require opt‑in for uploads. Strip user-identifiable data. |
485 | 526 |
|
486 | 527 | === Conclusion |
487 | 528 |
|
488 | | -Robust crash handling is essential for maintaining a high-quality Vulkan application. By implementing proper crash handling and minidump generation, you can quickly diagnose and fix issues that occur in production environments, leading to a more stable and reliable application. |
| 529 | +Robust crash handling is essential for maintaining a high-quality Vulkan application. Combine vendor GPU crash dumps (Aftermath, RGD, etc.) with CPU-side minidumps and thorough logging to quickly diagnose and fix issues in production. Treat minidumps as complementary context; the actionable details for graphics faults typically come from GPU crash dump tooling. |
489 | 530 |
|
490 | | -In the next section, we'll explore Vulkan extensions for robustness, which can help prevent crashes in the first place by making your application more resilient to undefined behavior. |
| 531 | +In the next section, we'll explore Vulkan extensions for robustness, which can reduce undefined behavior and help prevent crashes in the first place. |
491 | 532 |
|
492 | 533 | link:03_debugging_and_renderdoc.adoc[Previous: Debugging with VK_KHR_debug_utils and RenderDoc] | link:05_extensions.adoc[Next: Vulkan Extensions for Robustness] |
0 commit comments