mirror of
https://github.com/wolfpld/tracy.git
synced 2026-07-28 08:59:15 +00:00
12dc23f67e
Tests whether CUPTI recycles graphId values after cudaGraphExecDestroy, which would be the only scenario where the graphLaunchCache in TracyCUDA could serve stale entries for a non-matching exec handle. Result (H100, CUDA 12, CUPTI): graphId is a monotonically increasing counter that is never recycled. 22 create/instantiate/launch/destroy cycles produced unique IDs ranging from 2 to 65 (incrementing by 3 per cycle — one unit per node created during graph construction). This confirms that the stale-cache concern raised in code review is not a real risk in practice: two distinct exec handles always have distinct graphIds. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Tracy CUDA Graph GPU Zone Repro
Demonstrates that unpatched Tracy fails to show GPU zones for kernels
launched via CUDA Graphs (cudaGraphLaunch).
Root cause
When kernels are launched through CUDA Graphs, CUPTI delivers
CONCURRENT_KERNEL and MEMCPY activity records but no corresponding
API callback fires for the individual kernel launches. Tracy's
matchActivityToAPICall() always fails, and matchError() silently
drops every GPU zone.
Build and run
make
./repro
What to expect
| Tracy version | GPU zones shown |
|---|---|
| Unpatched | 0 |
| Patched (cuda-graph-gpu-zones.patch) | ~30 (10 launches x 3 ops) |
The graph structure
Each graph launch contains:
vector_addkernel (c = a + b)- Device-to-device memcpy
vector_addkernel (c = a + c)
The graph is launched 10 times, so 30 GPU operations total.