triton-ascend-verify-diagnose

Diagnoses Triton Ascend kernel verification failures from verifier precision logs and error distributions.

6|1|Updated Apr 19, 2026
One-click install
npx skills add https://github.com/xchang1121/op-autoresearch --skill triton-ascend-verify-diagnose-xchang1121
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: triton-ascend-verify-diagnose
Source: https://github.com/xchang1121/op-autoresearch/tree/main/skills/triton-ascend/evolved-fix/triton-ascend-verify-diagnose
Command: npx skills add https://github.com/xchang1121/op-autoresearch --skill triton-ascend-verify-diagnose-xchang1121

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a Triton Ascend kernel fails verification, raw verifier output (precision metrics, per-dimension error ranges, sample coordinates) is hard to interpret. This Skill turns that output into a concrete root-cause hypothesis—precision, mask, index, boundary, NaN/Inf, or store errors—so you fix the right code instead of guessing. ## Core Features & Use Cases - Precision line parsing: Interprets [precision] fields (hard, outlier, strict, mere, mare) and the strict/relaxed tolerance formulas to classify failure type before touching thresholds. - Per-dimension error analysis: Reads Error location per dimension ranges and coverage to distinguish boundary/tail bugs, tile mapping errors, and global formula or store mistakes. - Sample-value heuristics: Maps patterns like impl=0, magnitude mismatches, sign flips, and repeated values to likely causes such as mask over-restriction, stride errors, or buffer overwrite. - Use Case: A kernel fails with hard=254 and errors only in dim2: [4:5]; the Skill directs you to check that dimension's offset, stride, and tail mask rather than rewriting accumulation logic. ## Quick Start Ask the agent to diagnose the failed Triton Ascend kernel verification using the verifier log's precision line, per-dimension error distribution, and sample coordinates.

Frequently Asked Questions about triton-ascend-verify-diagnose

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I diagnose a Triton Ascend kernel verification failure?▼

Start with the verifier's [precision] line: if hard > 0, treat it as a logic, index, mask, or store bug; if hard=0 but outliers exceed the cap, treat it as a precision issue. Then use per-dimension error ranges and sample values to locate the faulty code region.

What do hard, outlier, and strict mean in Triton verifier output?▼

hard counts elements exceeding the relaxed tolerance, outlier counts elements between strict and relaxed tolerances against an allowed cap, and strict counts fully passing elements. Fix hard failures first; never tune thresholds before resolving them.

How to interpret per-dimension error location in kernel verification logs?▼

Each dim line shows the index range where errors occurred and unique-index coverage, as an independent projection. Localized ranges suggest boundary or stride bugs, while all dimensions showing [:] with many hard failures points to global formula, accumulation, dtype, or store errors.

Why does my Triton kernel output zeros where reference values are nonzero?▼

impl=0 with ref!=0 usually means the region was never computed or written: an overly strict store mask, a missed tail write, or padding being misused. Check tl.load/tl.store masks and boundary handling for the affected indices.

When should I not rely on per-dimension error distribution?▼

For low-dimensional outputs like [M] or [M,1], the distribution adds little beyond sample coordinates, so prioritize the [precision] line and sample values. Also ignore it entirely if the log lacks the Error location section rather than guessing dimension patterns.