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 unreachable. This Skill provides a disciplined workflow for porting existing Triton kernels in fla/ops/** to Gluon (triton.experimental.gluon) while preserving 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 async data movement, WGMMA/tcgen05 MMA, and persistent/warp-specialized scheduling, re-autotuning after each layer. - Triton-to-Gluon API mapping: a reference table covering @gluon.jit, gl.load/gl.store, BlockedLayout, NVMMASharedLayout, mbarrier pipelining, and manual multi-buffering replacing num_stages. - Compile-time and smem-budget management: autotune config pruning for heavily unrolled kernels, constexpr-switched resident vs streaming designs under the 228KB shared memory cap, and a pitfall checklist covering proxy fences, mbarrier phases, bitwise-cancellation traps, and NaN-poisoned OOB handling. - Use Case: A Gated DeltaNet kernel is register-bound and cannot grow its block size. Use this Skill to port it to Gluon with TMA loads tracked by mbarriers, freeing registers so blocks can grow, then verify forward and backward parity with the frozen pytest before benchmarking against the Triton baseline. ## Quick Start Port the Triton kernel in fla/ops/<op> to Gluon following the incremental sequence, keeping the frozen pytest passing at every step.
