What problem does it solve? Triton kernels can hit performance ceilings when register spills cap block sizes, num_stages pipelining underperforms, or Hopper/Blackwell hardware features like TMA, TMEM, and tcgen05 are needed but not exposed. This Skill provides a disciplined workflow for porting those kernels to Gluon while keeping numerical parity at every step. ## Core Features & Use Cases - Incremental Porting Sequence: Freeze the baseline pytest contract, do a literal translation with explicit layouts, then layer in cp.async/TMA data movement, WGMMA/tcgen05 MMA, and scheduling (persistent kernels, warp specialization) driven by profiling. - Triton-to-Gluon API Mapping: A concrete table mapping tl.load/tl.dot/num_stages to their Gluon equivalents, plus guidance on layouts, shared memory budgets, autotune pruning, and compile-time management for heavily unrolled kernels. - Pitfall Checklist: Covers proxy fences, mbarrier phase semantics, tma.store_wait behavior, bitwise-cancellation traps, and NaN-poisoned out-of-bounds handling. - Use Case: A bandwidth-bound attention kernel in fla/ops is register-bound on an H100. Use this Skill to port it to Gluon with TMA loads and per-slot mbarrier pipelining, verifying forward and backward parity against the frozen pytest after each layer. ## Quick Start Port the Triton kernel in fla/ops/attnres to Gluon following the incremental sequence, keeping the existing pytest passing after each step.
