cuTile-to-Triton Kernel Converter
Port cuTile GPU kernels to validated, tunable Triton implementations.
The skill scopes its stated purpose to cuTile-to-Triton conversion and requires testing and performance gates; however, it grants broad Read, Write, Grep, Glob, and Bash capabilities without per-action confirmation, least-privilege boundaries, sensitive-data guidance, rollback procedures, or isolation of external effects, so points are deducted.
The analyze-convert-validate-test-benchmark workflow is coherent and requires fixing failed gates; however, the static materials do not establish that key paths run successfully, and the examples contain unverified environment assumptions with limited abnormal-input handling and diagnosable failure feedback, so points are deducted.
The audience, trigger scenarios, TMA requirements, layout flags, performance regressions, and debugging cases are described fairly clearly; however, the core function assumes CUDA, cuTile, Triton, and TileGym test infrastructure, with no stated non-CUDA boundaries, version matrix, or Chinese-language support, so points are deducted.
The skill includes a name, version, description, licenses, author, tags, layered references, checklists, and multiple examples; however, it lacks a skill-specific changelog and explicit maintenance/update path, and the benchmark reports a missing recommended Examples section, so points are deducted.
The workflow, API mapping, TMA rules, performance pitfalls, and completion gates are directly useful for conversion work, and examples provide reference outputs; however, static review cannot confirm conversion correctness or performance targets, so substantial environment validation and human review remain necessary and points are deducted.
The supplied material includes source examples, test functions, a benchmark function, and an NVSkills-Eval report; however, the report provides no independently checkable raw logs, CI evidence, or reproducible coverage of key paths, leaving the conclusions largely claim-based and warranting a low score.
- The skill can run Bash and write files but defines no command allowlist, user confirmation, backup, or rollback procedure; isolate the worktree and review commands manually.
- The TMA requirements, regression multipliers, and example correctness were not independently verified in this static review; documented performance gates should not be treated as proven results.
- The skill depends on NVIDIA CUDA, cuTile, Triton, and TileGym test infrastructure and does not describe alternatives for mainland-China networks or environments without NVIDIA GPUs.
What does this skill do, and when should you use it?
This skill helps developers migrate cuTile @ct.kernel GPU kernels to Triton @triton.jit. It defines a gated analyze, convert, validate, test, and benchmark workflow covering API translation, TMA tensor descriptors, autotuned grids, and dual-layout kernels. It also provides troubleshooting paths for illegal addresses, shape mismatches, numerical mismatches, dtype issues, and stride problems. The skill is maintained by NVIDIA’s TileGym team and licensed under CC BY 4.0 AND Apache-2.0.
Reads cuTile source and runs grep-based pre-flight checks for kernel counts, loads, stores, launch patterns, constants, and layout flags; maps cuTile constructs such as ct.load, ct.store, ct.Constant, ct.launch, and ct.mma to Triton equivalents; creates or edits Triton kernels and host launch code; syntax-checks the result and runs relevant TileGym pytest targets; benchmarks Triton against cuTile; and routes runtime or numerical failures to dedicated debugging guidance.
- A TileGym developer needs to port an existing cuTile operator to Triton with explicit correctness and performance gates.
- A GPU-kernel engineer is debugging cudaErrorIllegalAddress, shape mismatch, or numerical mismatch in an existing Triton translation.
- A performance engineer converted a GEMM, BMM, or attention kernel and needs to investigate regressions involving TMA, autotuning, grid layout, or tail handling.
- A developer is translating kernels with transpose, transpose_v, or MLA-style paths and needs separate Triton kernels for different layouts.
- An attention or Gemma FMHA/GQA developer needs an optimization checklist before converting the inner loop.
What are this skill's strengths and limitations?
- Provides a clearly gated conversion workflow from source analysis through benchmarking.
- Covers common cuTile-to-Triton API mappings and runtime troubleshooting paths.
- Makes TMA tensor descriptors mandatory for applicable 2D+ block-shaped accesses and highlights severe regression risks.
- Includes dedicated guidance for dual layouts, autotuning, attention, and Blackwell optimization.
- Does not document installation of the CUDA, Triton, cuTile, or TileGym environment.
- Depends on an actual TileGym test and performance environment; the source provides no test results or platform coverage evidence.
- The process is intentionally heavyweight, requiring checklists, tests, and benchmarks even for straightforward ports.
- The README describes collection-level signatures, evaluation data, and benchmark artifacts, but those files are not included in the supplied SKILL.md content.
How do you install this skill?
Install the skill through the NVIDIA skills CLI:
npx skills add nvidia/skills --skill tilegym-converting-cutile-to-triton --yes
You may target a specific client, for example:
npx skills add nvidia/skills --skill tilegym-converting-cutile-to-triton --agent codex --yes
The README does not provide a separate source repository for this individual skill; it is installed from the NVIDIA/skills collection.
How do you use this skill?
After installation, invoke it with a task such as: “Convert this @ct.kernel cuTile kernel to Triton, then run the tests and performance benchmark.” The workflow requires creating a conversion checklist and proceeding through analyze → convert → validate → test → benchmark. A documented validation command is pytest tests/ops/test_<op>.py -k "triton" -vs; the exact test path, operator name, hardware, and environment setup are not specified and must be supplied by the user.
How does this skill compare with similar options?
Compared with keeping a kernel in cuTile, this skill is for teams that need a Triton implementation, Triton launch semantics, or Triton-specific performance tuning. It is not a replacement GPU-kernel framework; it is a migration workflow and reference set for cuTile-to-Triton work.