Support ingestion and processing of GPU crash dumps

[sentry-junior]

Problem Statement

Graphics-heavy applications produce a class of failure that CPU-side crash dumps
cannot explain: device removal, driver resets, and GPU-side faults. Vendor tooling
produces its own dump artifacts for these, containing GPU state, the faulting shader
or draw call, and driver context at the time of failure.

Sentry ingests CPU minidumps and symbolicates them well. GPU dumps have no ingestion
path, so the crashes that most often make an application unusable on a specific
hardware and driver combination are the ones with the least information in the crash
tool.

In practice this means:

• GPU faults present in the CPU stack as a generic device-lost or driver error, with
  no indication of the underlying cause.
• Teams cannot correlate GPU faults with driver version, GPU model, or graphics API
  version at scale, so they cannot distinguish a widespread driver regression from
  an application bug.
• The dumps are already produced client-side. They simply have nowhere to go.

This is particularly acute for teams shipping to a wide consumer hardware surface,
where testing every driver and GPU combination is not possible and post-release
telemetry is the only realistic way to find these failures.

Solution Brainstorm

• Accept GPU crash dumps as a first-class attachment type with dedicated parsing,
  rather than as an opaque blob.
• Surface the GPU-side fault context on the event alongside the CPU stack trace.
• Support grouping and search on GPU fault attributes such as driver version, GPU
  model, and faulting shader, so a driver-specific regression appears as one issue
  rather than scattered across many.

Product Area

Issues

Requested by Saad Khan.

--

View Junior Session [Sentry]

[linear-code]

ENG-8510