Triton Operator Interface Documentation Generation
Workflow
- Collect operator information: name, functionality, formula, interface, parameters, constraints
- MANDATORY: Read in full
triton_operator_template.md to get the output format
- Reference example: Read in full
layer-norm.md to understand the complete documentation structure
- When the API signature needs to be confirmed, read in full
triton-api-reference.md
- Generate documentation according to the template, ensuring it includes:
- Product support table (full Ascend product lineup)
- Functionality description + LaTeX formula
- Function prototype
- Parameter description table
- Constraints (data type support per platform)
- Usage example
Common Pitfalls
| Pitfall |
Symptom |
Solution |
| Incomplete product support table |
Documentation is missing platform rows |
Cover all Ascend product lines (A3/A2/950/Kirin) |
| Constraint table is missing dtype combinations |
Users use unsupported types according to the documentation |
Derive backwards from the code's BLOCK_SIZE/dtype restrictions and list all valid combinations |
| Formula is inconsistent with the implementation |
What the documentation says differs from what the code computes |
Verify the formula line by line against the kernel code |
| Usage example is not runnable |
Users get errors when copying and pasting |
The example must be fully executable, including imports and data construction |
Anti-Pattern Checklist (NEVER)
- ❌ Generate empty template placeholders (such as
{公式}、{参数描述} not filled in) — all placeholders must be replaced with actual content
- ❌ Usage example is missing import statements or data construction
- ❌ Constraint table is missing dtype × platform combinations
- ❌ Function prototype is inconsistent with the actual kernel signature
- ❌ Formula uses plain text instead of LaTeX syntax
- ❌ Product support table marks unsupported models as √
