Tilegym Cutile Python

cuTile Python Programming Skill

You are an expert in cuTile programming, specializing in writing high-performance GPU kernels using cuTile's tile-based programming model. This skill provides comprehensive guidance for creating, debugging, and optimizing cuTile kernels.

Overview

cuTile is a parallel programming model for NVIDIA GPUs with a Python-based DSL that automatically leverages advanced hardware capabilities like tensor cores. This skill helps you write efficient, correct cuTile code.

When to Use This Skill

Invoke this skill when you need to:

• Write cuTile GPU kernels from scratch
• Convert tensor operations to cuTile implementations
• Debug or fix cuTile kernel code
• Optimize cuTile kernels for performance
• Understand cuTile API and programming patterns
• Validate cuTile implementations
• Find and adapt examples from available reference sources

Optionally specify when invoking:

• Target tensor shapes
• Data types (default: float16)
• Performance requirements
• Any special constraints

Reference Documentation

cuTile Language Specification — https://docs.nvidia.com/cuda/cutile-python. Covers the execution model, data and memory models, debugging, compilation, and every public op (load/store, factories, reductions, scans, matmul, selection, math, bitwise, comparisons, atomics, metaprogramming, classes, enums, autotuning).

Implementation Guidelines (in the guidelines/ directory):

• 01_implementation_lessons.md - Important lessons and implementation rules
• 02_code_generation_rules.md - Specific code generation rules and patterns
• 03_concepts.md - Core concepts: tile size restriction, memory operations, kernel fusion, default rules

Examples

Before starting any cuTile programming task, always search for existing examples first. TileGym is the primary reference; the packaged examples/ directory complements it for ops TileGym does not yet cover (convolution, pooling, scan, GEMV, 4D matmul, split-k GEMM, group_norm).

The skill supports two installation contexts:

• Inside a TileGym checkout (<repo>/skills/tilegym-cutile-python/, or <repo>/.agents/skills/tilegym-cutile-python/ / <repo>/.claude/skills/tilegym-cutile-python/ via the backward-compat symlinks) — TileGym ops are at <repo>/src/tilegym/ops/cutile/.
• Installed elsewhere (e.g. ~/.agents/skills/tilegym-cutile-python/, ~/.claude/skills/tilegym-cutile-python/, or inside a different repo) — clone TileGym once to ${TILEGYM_SKILL_CACHE_DIR:-~/.cache/tilegym}/TileGym and use its src/tilegym/ops/cutile/.

See examples/tilegym_and_examples_guide.md for the full search order, directory layout, and cache-vs-repo decision procedure.

When to Clarify Before Implementation

For complex or ambiguous tasks, present approach options to the user before coding. This prevents wasted effort on the wrong implementation.

Clarify for These Task Types

Act Directly for These Task Types

• Clear, specific requests: "Write a ReLU kernel for shape (1024, 1024)"
• Bug fixes with reproduction: "This kernel crashes on line 42"
• API questions: "How do I use ct.gather?"
• Example adaptations: "Adapt the TileGym softmax for my shapes"

How to Clarify

When clarification is needed:

1. Briefly explain why multiple approaches exist
2. Present 2-3 concrete options with tradeoffs
3. Recommend one option if there's a clear best choice
4. Ask the user to choose before proceeding

Example:

Your request "optimize this matmul" could go several directions:

1. **Persistent kernel** - Best for small matrices, faster, more complex code
2. **Tile size tuning** - Moderate gains, minimal code changes
3. **TMA prefetching** - Best for large matrices, requires Hopper+ GPU

I recommend option 2 for a first pass. Which approach would you like?

Complexity Assessment: Simple vs. Orchestrated Workflow

Before starting implementation, assess the complexity of the request to choose the right workflow.

Use the Simple Workflow (Steps 0-6 below) when:

• Single kernel task (e.g., ReLU, softmax, one matmul)
• Bug fix or optimization of an existing kernel
• API question or example adaptation
• Clear, single-operation request

Use the Deep Agent Orchestration Workflow when ANY of these apply:

• 3+ distinct operations that need separate kernels (e.g., "implement a transformer block with attention, FFN, and layer norm")
• Multiple user-defined functions in the input code (e.g., custom_activation(), custom_norm())
• Inter-kernel data dependencies where output of one kernel feeds into another
• PyTorch nn.Module with multiple layers in forward()
• Explicit decomposition request (e.g., "break this into fused kernels")

When orchestration is needed, follow the Deep Agent Orchestration Workflow section. Otherwise, continue with the Instructions below.

Deep Agent Orchestration Workflow

For complex tasks requiring 3+ kernels, inter-kernel dependencies, or multi-layer nn.Module decomposition, use the orchestrated multi-agent pipeline. The main agent acts as an orchestrator (not a coder) — sub-agents handle reference reading and code generation.

Pipeline: Op Tracer (optional) → Analyzer → Kernel Agents (parallel) → Composer → Main Agent validates

For the complete step-by-step workflow (Steps O-0 through O-4), prompt templates, and error handling, see orchestration/workflow.md.

For the orchestration architecture, agent hierarchy, and kernel spec format, see orchestration/overview.md.

Instructions

Follow these steps when writing cuTile kernels (simple workflow for single-kernel tasks).

NOTE: Skip this entire section if using the Deep Agent Orchestration Workflow above. The orchestration workflow has its own steps (O-0 through O-4). Do NOT combine both workflows - that leads to the main agent reading all reference files AND spawning sub-agents, which wastes context.

Step 0: Search Examples and Consult References (MANDATORY)

Objective: Find existing examples and review relevant documentation

Example Search (Two-Step Strategy):

1. Search TileGym (src/tilegym/ops/cutile/) first for similar cuTile kernel patterns.
2. If TileGym has no match, search the packaged examples/ directory (part of this skill).
3. Read relevant example files to understand implementation patterns.

Complex Algorithm Translation (flash attention, fused ops, etc.): When implementing complex algorithms, follow this systematic approach:

1. Analyze the PyTorch implementation: Understand the mathematical operations, data flow, key computational patterns, memory access patterns, and any special optimizations or constraints.
2. Study relevant cuTile examples: Review examples for similar operations — existing examples often provide the exact patterns you need. Copy and adapt working patterns rather than reinventing the wheel.
3. Implement the cuTile version: Map PyTorch operations to cuTile primitives, apply kernel fusion where appropriate, ensure proper tile indexing and memory management, and validate against the PyTorch reference.

Reference Documentation:

• Language Spec — https://docs.nvidia.com/cuda/cutile-python
• Implementation Guidelines (guidelines/ 01–03) — Lessons, rules, and concepts

Step 1: Understand the Problem

Objective: Clearly define what the kernel needs to compute

• Identify input/output tensors and their shapes/dtypes
• Understand the mathematical operations required
• Determine data dependencies and computation flow
• Analyze memory access patterns for optimization opportunities

Working with user-provided reference implementations:

1. Preserve Reference Code: Keep the original PyTorch reference implementation intact. Only remove code that is clearly redundant or unnecessary.
2. Conservative Approach: Do not modify or rewrite the reference implementation unless explicitly required. The reference serves as the ground truth for correctness validation.
3. Seek Clarification: If you are uncertain about the correctness or intent of any part of the reference code, ask the user for clarification before proceeding.
4. Maintain Functionality: Any changes to the reference code must preserve the original functionality and behavior.

Step 2: Design Kernel Architecture

Objective: Plan the kernel structure

• Determine optimal block/tile sizes for parallelization (consider multiples of 32)
• Calculate grid dimensions based on tensor sizes using ct.cdiv(size, block)
• Design block indexing strategy using ct.bid()
• Handle edge cases where tensor size is not divisible by block size

Step 3: Prepare Type System and Constants

Objective: Ensure proper type annotations

• Identify all constant values that need type annotations
• Add proper type annotations using ct.Constant[type] for all constants
• Choose appropriate cuTile dtypes (ct.float32, ct.float16, ct.int32, etc.)
• Ensure block sizes and other parameters are properly typed

Step 4: Implement the Kernel

Objective: Write the cuTile kernel function

• Create @ct.kernel decorated kernel function with proper signature
• Add required parameters (input tensors, output tensor, typed constants)
• Implement block indexing with appropriate ct.bid() calls
• Use ct.load() for input tensor access with proper indexing and tile shapes
• Perform operations on loaded tiles using cuTile tile operations
• Use ct.store() for output tensor writing with correct indexing

Step 5: Prepare and Launch

Objective: Set up tensor inputs and launch kernel

• Ensure all input tensors are on CUDA device using .cuda() or .to("cuda")
• Verify tensor dtypes are compatible with cuTile
• Handle tensor contiguity requirements using .contiguous() if needed
• Launch kernel with proper grid dimensions

Step 6: Validate and Test

Objective: Ensure correctness

• Verify kernel compiles without errors
• Test with various tensor sizes (aligned and unaligned to tile size)
• Validate results against reference implementation if available
• Check boundary conditions and edge cases

Validation Loop (MANDATORY)

IMPORTANT: After generating cuTile code, you MUST execute it to verify correctness. Do not just write the file - run it and fix any issues.

Validation Workflow

┌─────────────────────────────────────────────────────────────┐
│  1. Generate Code                                           │
│     - Write cuTile kernel with inline validation to file    │
│                                                             │
│  2. Execute Code                                            │
│     - Run: python <filename>.py                             │
│                                                             │
│  3. Check Results                                           │
│     ├─ Compilation error? → Fix syntax/type issues → Retry  │
│     ├─ Runtime error? → Fix kernel logic → Retry            │
│     ├─ Validation FAIL? → Fix numerical issues → Retry      │
│     └─ Validation PASS? → Done ✓                            │
└─────────────────────────────────────────────────────────────┘