Triton and TLX development use a small set of complementary tools. Start from the question you need to answer rather than collecting every trace at once.
| Tool | Best used for |
|---|---|
| TritonParse | Capturing compilation and launch events, extracting reproductions, comparing IR, and bisecting compiler regressions |
| Triton-MPP | Classifying compute, memory, occupancy, and latency bottlenecks with targeted profiling passes |
| CUTracer | Inspecting SASS-level execution, warp progress, TMA/MMA activity, deadlocks, and race candidates |
| Compute Sanitizer | Runtime checks for invalid memory access, uninitialized values, synchronization errors, and shared-memory hazards |
| TritonBench | Reproducible kernel and workload benchmarking across implementations and shapes |
| TLX Agent | Running a harness-driven optimization loop with correctness, profiling, promotion, and winner commits |
| Proton | Instrumenting Triton kernels and collecting performance data with low-level execution context |
| triton-lint | Static checks for common Triton correctness and performance anti-patterns |
Suggested workflow
Create a stable single-kernel reproduction with fixed shapes and configuration.
Use TritonParse to preserve compilation inputs and compare good and bad builds.
Use Triton-MPP or a hardware profiler to classify the performance limit.
Add CUTracer or Compute Sanitizer only when runtime ordering, races, or memory access are suspect.
Confirm improvements with TritonBench or the repository's correctness and performance harnesses.
Use the TLX Agent when you want that validated harness to drive an automated candidate, profiling, and promotion loop.
The debugging guide provides symptom-driven workflows for performance and numerical issues.