CuTile Autotuning Guide
Design, implement, and validate low-overhead autotuning for CuTile GPU kernels.
No malware, credential theft, or covert exfiltration is evident; the scope is limited to CuTile autotuning and includes a DISABLE_AUTOTUNE fallback and an in-place split-buffer pattern. Deductions apply because it does not require confirmation for GPU compilation/benchmark resource use, disclose data flow, specify dependency versions, address concurrent cache safety or rollback, or clearly document operational ownership beyond repository attribution.
The workflow, cache pattern, architecture filtering, pitfalls, and examples are fairly coherent, with examples covering occupancy, matmul, and in-place RoPE. Static review cannot confirm API or hardware compatibility; error handling relies mainly on assertions and lacks diagnostic behavior for empty search spaces, compilation failures, invalidated caches, and anomalous benchmarks, so the score remains below the static ceiling.
Trigger terms, intended scenarios, decision tree, capability scope, and explicit out-of-scope boundaries are clear. Deductions apply because the skill assumes CUDA/CuTile/NVIDIA GPU availability, omits a version matrix and fuller architecture/input boundaries, provides no Chinese-language guidance, and does not establish mainland-China network reachability.
The documentation has useful routing, progressive references, examples, pitfalls, license metadata, and cache/disable-switch guidance. Deductions apply for missing metadata.author, versioning, changelog, maintenance responsibility, and update path; the supplied evaluation report also identifies a missing recommended Examples section, duplicate content, and deep reference nesting.
The skill offers directly reusable patterns for exhaustive_search, caching, launch, fallback, and validation, giving it clear marginal value over ad hoc implementation. Deductions apply because static evidence cannot establish that the examples run or deliver performance gains; the benchmark report records an overall FAIL verdict and only one positive task, leaving benefits and boundaries insufficiently validated.
Committed examples, fixed-config comparisons, reference implementations, test functions, and a benchmark report provide a partial audit trail. Deductions apply because nothing was executed in this review, the report lacks externally verifiable links or complete reproduction logs, and independent corroboration and key-path coverage are limited, so the score stays within the static ceiling.
- Confirm CUDA, CuTile API, GPU architecture, and dependency versions before use; the first call compiles and benchmarks multiple configurations and may consume substantial time and GPU resources.
- Do not treat the examples or benchmark report as reproduced in the current environment; separately verify correctness, DISABLE_AUTOTUNE fallback, in-place inputs, and concurrent cache behavior.
- Add author, version, changelog, maintenance/update ownership, and diagnosable handling for compilation failure, empty configurations, and hardware mismatch.
What does this skill do, and when should you use it?
This skill helps CuTile GPU-kernel developers add and maintain autotuning. It centers on a tune-once, cache, and direct-`ct.launch` pattern built around `exhaustive_search`. The guidance covers occupancy search, tunable tile sizes, `num_ctas`, architecture-specific configurations, and common failure modes. Its scope is autotuning configuration, not kernel-algorithm or memory-access changes.
It guides an agent to classify a kernel, choose search dimensions, build a final candidate set of no more than 30 configurations, call exhaustive_search, cache both the winning configuration and tuned kernel, and launch through ct.launch. It also specifies split-buffer handling for in-place kernels, correctness testing with DISABLE_AUTOTUNE=1, and A/B benchmarking against a fixed best-known configuration.
- A CuTile developer adding occupancy autotuning to a new elementwise, reduction, or LayerNorm kernel.
- A GPU-kernel developer designing tile-size, occupancy, and `num_ctas` searches for matmul, FMHA, FP8, or fused multi-GEMM kernels.
- A maintainer debugging corruption after the first run, an empty search space, or excessive compilation time.
- A performance engineer pruning losing configurations from an existing autotuning setup.
What are this skill's strengths and limitations?
- Provides an end-to-end workflow from kernel classification and search-space design through A/B validation.
- Addresses in-place corruption, caching, architecture filters, compilation cost, and `replace_hints` recompilation on hot paths.
- Includes architecture-aware guidance for sm80–sm120 and requires retaining the original fixed configuration as a candidate.
- Covers autotuning configuration only; math flags, performance hints, memory-access patterns, and algorithm changes are out of scope.
- Initial tuning requires compilation and search, and the skill notes that CuTile compilation is relatively heavy; final code should stay within 30 configurations.
- The source does not provide an independent test suite, actual hardware coverage, or a quantitative benchmark report for this specific skill.
How do you install this skill?
Use the repository README installation flow: npx skills add nvidia/skills --skill tilegym-cutile-autotuning --yes. To target Codex explicitly, use npx skills add nvidia/skills --skill tilegym-cutile-autotuning --agent codex. The source does not document a separate standalone installation procedure for this skill.
How do you use this skill?
After installation, invoke it for a relevant CuTile task, for example: “Design and implement autotuning for this CuTile kernel containing cuda.tile.tune, then validate correctness and performance.” Trigger signals include exhaustive_search, replace_hints, hints_fn, cuda.tile.tune, autotune in filenames, and correctness or performance issues in autotuned CuTile kernels.
How does this skill compare with similar options?
The skill explicitly contrasts CuTile autotuning with Triton autotuning: Triton uses @triton.autotune and Config objects, while CuTile uses exhaustive_search, SimpleNamespace configurations, user-managed caching, and ct.launch; CuTile does not use num_warps or num_stages.