@kernaut/kernaut-resources 0.1.17-beta.1 → 0.1.18

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/nvidia/kernels/nvfp4-gemv.md

@@ -1,270 +0,0 @@
----
-id: kernel-nvfp4-gemv
-title: NVFP4 Batched GEMV
-type: kernel
-architectures:
-- sm100
-- sm100a
-tags:
-- gemv
-- nvfp4
-- fp4
-- block-scale
-- cache-policy
-- register-budgeting
-- vectorized-loads
-confidence: source-reported
-evidence_level: spec
-reproducibility: snippet
-kernel_types:
-- gemv
-- batched-gemv
-languages:
-- cuda-cpp
-- ptx
-related:
-- hw-nvfp4
-- kernel-nvfp4-gemm
-- pattern-memory-bound
-sources:
-- contest-gpumode-p1
-- blog-yue-nvfp4
-- blog-amandeep-nvfp4
-performance_claims:
-- gpu: B200
-  dtype: nvfp4
-  shape: M=7168, K=16384, L=1
-  metric: latency_us
-  value: 22.4
-  utilization: ~2.6x of SOL (8.6us)
-  source_id: contest-gpumode-p1
-artifact_dir: artifacts/kernels/nvfp4-gemv
----
-
-# NVFP4 Batched GEMV
-
-## Overview
-
-NVFP4 Batched GEMV is a memory-bound kernel computing batched matrix-vector products with NVFP4 (E2M1) block-scaled inputs on B200 GPUs. Unlike compute-bound GEMM, GEMV is dominated by memory bandwidth utilization (each FP4 element is used only once in the dot product), making PTX-level memory access control, cache policy differentiation, and register budgeting the critical optimization levers.
-
-This was Problem 1 of the GPU Mode NVFP4 Hackathon (Nov 2025). The theoretical speed-of-light is ~8.6us for the largest config, limited by B200's 8 TB/s HBM3e bandwidth. Top performers achieved ~22.4us (2.6x off SOL), reflecting the overhead of FP4 decoding and scale factor application.
-
-## Problem Specification
-
-```
-Inputs:
-  a: (M x K x L) NVFP4 packed matrix
-  b: (1 x K x L) NVFP4 packed vector
-  sfa: (M x K/16 x L) FP8 E4M3 scale factors for a
-  sfb: (1 x K/16 x L) FP8 E4M3 scale factors for b
-  sf_a_global, sf_b_global: FP32 per-tensor global scales
-
-Output:
-  c: (M x 1 x L) FP16
-
-Computation per element:
-  c[m][l] = sum_k( sf_a_global * sfa[m][k/16][l] * deq(a[m][k][l])
-                  * sf_b_global * sfb[0][k/16][l] * deq(b[0][k][l]) )
-
-Benchmark configs:
-  Config 1: M=7168, K=16384, L=1
-  Config 2: M=4096, K=7168,  L=8
-  Config 3: M=7168, K=2048,  L=4
-```
-
-## Key Optimization: PTX-Level Control
-
-Raw PTX provides critical performance gains over C intrinsics for FP4 decoding and memory access:
-
-```asm
-; FP4 to FP16 conversion: hardware instruction
-; Converts two packed E2M1 values to a pair of FP16 values
-cvt.rn.f16x2.e2m1x2 %result, %fp4_packed;
-
-; Byte unpacking: PTX mov.b32 is faster than manual bitwise ops
-; Instead of: val = (packed >> (i*4)) & 0xF  (multiple shifts + masks)
-; Use: direct byte decomposition
-mov.b32 {tmp0, tmp1, tmp2, tmp3}, %packed_word;
-
-; This eliminates the shift-mask chain entirely
-; Key insight: PTX byte unpacking leverages hardware byte decomposition
-```
-
-## Cache Policy Differentiation
-
-Different data access patterns require different cache strategies:
-
-```asm
-; Matrix A: streamed once per row, never reused across thread blocks
-; Bypass L1 to avoid polluting cache with one-shot data
-ld.global.L1::no_allocate.v4.u64 {a0,a1,a2,a3}, [addr_a];
-
-; Vector B: reused across all M rows in a thread block
-; Keep hot in L1 for fast reuse
-ld.global.L1::evict_last.v4.u64 {b0,b1,b2,b3}, [addr_b];
-
-; Rank 1 solution: used different qualifiers depending on K-dimension variant
-; K=16384 (large): aggressive L1 bypass for A
-; K=2048 (small): different balance since B is smaller relative to cache
-```
-
-## Register Budgeting
-
-Lower register counts force higher occupancy, which is critical for memory-bound kernels where latency hiding dominates:
-
-```cpp
-// Rank 1: aggressive register limit for maximum occupancy
-// nvcc -maxrregcount=32
-// Fewer registers -> more warps/SM -> better memory latency hiding
-
-// Rank 3: slightly relaxed for more ILP
-// nvcc -maxrregcount=45
-
-// Launch bounds to complement register budgeting
-__launch_bounds__(256, 4)  // 256 threads/block, 4+ blocks per SM
-__global__ void nvfp4_gemv_kernel(...) {
-    // ...
-}
-
-// The measurable difference between 32 and 45 registers shows
-// that occupancy is the dominant factor for memory-bound kernels
-```
-
-## Per-K Specialization
-
-Compile separate kernels per K dimension, each with full loop unrolling and tuned configs:
-
-```cpp
-// Each K variant compiled separately with optimal configuration
-template <int K_SIZE, int BLOCK_M, int MAX_REG>
-__global__ __launch_bounds__(THREADS, MIN_BLOCKS)
-void nvfp4_gemv_specialized(
-    const uint8_t* __restrict__ a,
-    const uint8_t* __restrict__ b,
-    const uint8_t* __restrict__ sfa,
-    const uint8_t* __restrict__ sfb,
-    half* __restrict__ c,
-    float sf_a_global, float sf_b_global,
-    int M
-) {
-    float acc = 0.0f;
-
-    // Full unroll: compiler knows K_SIZE at compile time
-    #pragma unroll
-    for (int k = 0; k < K_SIZE / ELEMENTS_PER_LOAD; k++) {
-        // Load FP4 packed data
-        uint64_t a_packed = load_fp4(a, row, k);
-        uint64_t b_packed = load_fp4(b, 0, k);
-
-        // Dequantize via PTX
-        half2 a_vals = cvt_e2m1x2(a_packed);
-        half2 b_vals = cvt_e2m1x2(b_packed);
-
-        // Apply block scales
-        float sa = sfa[row * (K_SIZE/16) + k/2];
-        float sb = sfb[k/2];
-
-        // Accumulate
-        acc += (float)a_vals.x * (float)b_vals.x * sa * sb;
-        acc += (float)a_vals.y * (float)b_vals.y * sa * sb;
-    }
-
-    // Apply global scales and store
-    c[row] = __float2half(acc * sf_a_global * sf_b_global);
-}
-
-// Dispatch: K=2048 uses BLOCK_M=8, maxreg=32
-//           K=7168 uses BLOCK_M=4, maxreg=40
-//           K=16384 uses BLOCK_M=2, maxreg=32
-```
-
-## Vectorized Loads
-
-128-bit and 256-bit vector loads maximize bandwidth utilization:
-
-```asm
-; 128-bit vector load (16 bytes = 32 FP4 elements)
-ld.global.v2.u64 {r0, r1}, [addr];
-
-; 256-bit vector load (32 bytes = 64 FP4 elements)
-ld.global.v4.u64 {r0, r1, r2, r3}, [addr];
-
-; Only effective when combined with PTX byte unpacking
-; to avoid bitwise overhead in the subsequent unpack stage
-; Without proper unpacking, wide loads just move the bottleneck
-```
-
-## Data Reuse (Rank 2 Approach)
-
-Since B is shape (1 x K x L), all M rows multiply against the same B vector:
-
-```cpp
-// Load B vector into shared memory once per thread block
-// All BLOCK_M rows reuse the same B data
-__shared__ half b_shared[K_TILE];
-
-// Cooperative load: all threads in block load a portion of B
-for (int i = threadIdx.x; i < K_TILE; i += blockDim.x) {
-    b_shared[i] = dequant_fp4(b[i], sfb[i/16]) * sf_b_global;
-}
-__syncthreads();
-
-// Each thread computes dot product of its A row with shared B
-float acc = 0.0f;
-for (int k = 0; k < K_TILE; k++) {
-    acc += (float)a_dequant[k] * (float)b_shared[k];
-}
-
-// Reduces global memory traffic by BLOCK_M ratio
-```
-
-## Performance Progression
-
-Documented progression from Yue's hackathon blog:
-
-| Stage | Technique | Latency |
-|-------|-----------|---------|
-| CuTe DSL baseline | Basic CuTe partition/copy | ~100us |
-| Coalesced access | Fix memory access patterns | 443us -> 39us |
-| Hardware intrinsics | cvt.rn.f16x2.e2m1x2 | ~39us |
-| PTX assembly | Full PTX with byte unpacking | ~27us |
-| ILP optimization | Instruction-level parallelism | ~22.9us |
-| Final submission | All combined | 22.392us |
-
-## Key Lessons
-
-1. **Memory-bound kernels need bandwidth-first thinking**: Arithmetic optimizations have minimal impact; focus on memory access patterns, cache policies, and vectorized loads
-2. **PTX gives real control on Blackwell**: The gap between C intrinsics and hand-written PTX was substantial (443us to 27us in one journey)
-3. **Profile first**: "Run Nsight Compute to confirm memory-bound behavior" (Amandeep's lesson after 12 attempts)
-4. **Register budgeting matters**: Lower registers -> higher occupancy -> better memory latency hiding
-5. **TMEM is irrelevant**: Memory-bound kernels do not benefit from TMEM (it helps compute-bound only)
-
-## When to Use
-
-- Decode-time MLP with batch size 1 (matrix-vector product)
-- Any NVFP4 workload where arithmetic intensity is too low for tensor cores
-- Memory-bound operations with FP4 quantized weights
-
-## Caveats
-
-- SM100/SM100a only (native FP4 decode instructions)
-- PTX-level optimizations are fragile across CUDA toolkit versions
-- Per-K specialization increases binary size (one kernel per K variant)
-- Speed-of-light is bounded by B200 memory bandwidth (8 TB/s)
-
-## Sources
-
-- [GPU Mode NVFP4 Hackathon](https://github.com/gpu-mode/reference-kernels)
-- [Yue's Hackathon Journey](https://yue-zhang-2025.github.io/2025/12/02/blackwell-nvfp4-kernel-hackathon-journey.html)
-- [Twelve Attempts (Amandeep)](https://amandeepsp.github.io/blog/nvfp4-blackwell-gemv/)
-- [Simon's NVFP4 GEMV Blog](https://veitner.bearblog.dev/nvfp4-gemv/)
-
-## Full Reference Implementation
-
-Local verbatim upstream code lives in [`artifacts/kernels/nvfp4-gemv/full/`](../../../artifacts/kernels/nvfp4-gemv/full/) (see its `PROVENANCE.yaml` for the pinned upstream SHA and byte-verified SHA-256). Labeled derived variants — including a naive/teaching skeleton — live in [`artifacts/kernels/nvfp4-gemv/variants/`](../../../artifacts/kernels/nvfp4-gemv/variants/).
-
-Query via:
-
-```bash
-python3 scripts/get_page.py kernel-nvfp4-gemv --include-code
-```

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/nvidia/kernels/sparse-mla.md

@@ -1,138 +0,0 @@
----
-id: kernel-sparse-mla
-title: Sparse MLA (DeepSeek V3.2)
-type: kernel
-architectures:
-- sm100
-- sm90
-tags:
-- sparse-attention
-- mla
-- fp8
-- attention
-- decode
-- prefill
-confidence: source-reported
-evidence_level: spec
-reproducibility: snippet
-kernel_types:
-- sparse-attention
-- mla
-- attention
-- decode
-- prefill
-languages:
-- cuda-cpp
-- cute-dsl
-related:
-- kernel-flashmla
-- kernel-nsa
-- hw-tcgen05-mma
-sources:
-- blog-flashmla
-- blog-vllm-deepseek-v3-sparse
-- blog-nsa
-performance_claims:
-- gpu: B200
-  dtype: fp8
-  shape: sparse prefill, seqlen=32k, topk=2048
-  metric: TFLOPS
-  value: 1450
-  utilization: FP8 sparse compute bound
-  source_id: blog-flashmla
----
-# Sparse MLA (DeepSeek V3.2 Sparse Attention)
-
-## Overview
-
-Sparse Multi-head Latent Attention introduced in DeepSeek V3.2. Two-stage pipeline: (1) Lightning Indexer selects top-K tokens per query via FP8 scorer, (2) MLA runs only over selected tokens. This reduces decode attention compute from O(seqlen) to O(topk=2048) tokens, critical for long-context serving.
-
-## Architecture
-
-```
-Query q_t (new token embedding)
-   │
-   ▼
-┌────────────────────────┐
-│ Lightning Indexer      │   FP8 scorer, per-query top-K selection
-│ - FP8 KV cache          │   h64, d128, topk=2048, page_size=64
-│ - Compute q·k_i scores  │
-│ - Select top-2048 i     │
-└────────────────────────┘
-   │ selected_indices [2048]
-   ▼
-┌────────────────────────┐
-│ Sparse MLA              │   Standard MLA but only over selected
-│ - Gather selected K,V   │   h16, ckv512, kpe64, topk=2048
-│ - Attention compute     │
-│ - Output y_t            │
-└────────────────────────┘
-```
-
-## Token Layout
-
-Each KV cache entry is 656 bytes:
-- 512 bytes: FP8 compressed KV data
-- 16 bytes: FP32 per-block scale factors
-- 128 bytes: BF16 RoPE embeddings (for indexer positional encoding)
-
-Block size fixed at 64 (FlashMLA requirement).
-
-## Kernel Patterns
-
-### Lightning Indexer (FP8 Score Compute)
-```cuda
-// Score each KV block against query using FP8 block-scale MMA
-// Reduce to per-block max, then top-K selection across blocks
-
-__global__ void lightning_indexer_kernel(
-    const fp8_t* q_fp8,           // [h, d] query (FP8 quantized)
-    const fp8_t* kv_cache_fp8,    // [num_blocks, 64, d] paged
-    const fp8_t* kv_scales,
-    float* scores_out,            // [num_blocks] per-block max score
-    int num_blocks
-) {
-    // Each threadblock handles one KV block's score
-    uint32_t tmem = tmem_alloc(64);
-    tcgen05_mma_f8(q_smem, k_block_smem, tmem);
-    // Reduce inside block to max score
-    // Write per-block score
-}
-
-// Separate top-K selection kernel across the num_blocks score array
-```
-
-### Sparse Attention Gather
-```cuda
-// After top-K selection gives indices, gather K,V from paged cache
-// Then run standard MLA on the gathered subset
-
-__global__ void sparse_mla_decode_kernel(
-    const int* topk_indices,      // [2048] selected block indices
-    const fp8_t* kv_cache,        // paged KV (656 bytes/token)
-    const half* q,                // [16, 576] MLA query
-    half* output
-) {
-    // Load q into registers/SMEM
-    // For each selected block:
-    //   gather K,V block (FP8) → dequant to BF16 → MMA
-    // Online softmax accumulation
-    // Final weighted sum
-}
-```
-
-## Performance
-
-| Variant | GPU | TFLOPS | Notes |
-|---------|-----|--------|-------|
-| Dense MLA decode | H800 | 660 (BF16) | 3000 GB/s, compute-bound |
-| Sparse MLA decode | H800 | 410 (FP8) | Token-level sparsity |
-| Sparse MLA decode | B200 | 350 (FP8) | Lower because bandwidth dominates decode |
-| Dense prefill | B200 | 1460 (BF16) | tcgen05 peak |
-| Sparse prefill | B200 | 1450 (FP8) | FP8 sparse matches BF16 dense |
-
-## When To Use
-
-- Long-context LLM serving (32K+)
-- DeepSeek V3.2 and similar MLA architectures
-- Serving workloads where per-token decode latency matters

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/nvidia/languages/cuda-cpp.md

@@ -1,110 +0,0 @@
----
-id: lang-cuda-cpp
-title: "CUDA C++ for Blackwell Kernels"
-type: language
-tags: [cuda-cpp, ptx, tcgen05, tmem]
-related: [lang-ptx, hw-tcgen05-mma, hw-tmem, blog-tcgen05-tutorial]
-sources: [blog-tcgen05-tutorial, doc-nvidia-tuning-guide, blog-yue-nvfp4]
-reproducibility: snippet
-architectures: [sm100, sm100a]
-languages:
-- cuda-cpp
-confidence: source-reported
-evidence_level: spec
----
-
-## Overview
-
-Plain CUDA C++ with inline PTX is used for hand-optimized Blackwell kernels. The tcgen05 tutorial achieved 98% of reference GEMM performance using this approach.
-
-## tcgen05 via Inline PTX
-
-```cuda
-// Allocate TMEM
-__device__ void tmem_alloc(uint32_t* addr, uint32_t num_cols) {
-    asm volatile(
-        "tcgen05.alloc.cta_group::1.sync.aligned %0, %1;"
-        : "=r"(*addr) : "r"(num_cols)
-    );
-}
-
-// Issue MMA (single thread, typically warp 1 lane 0)
-// idesc_c/idesc_d: immediate descriptors for accumulator C and output D
-__device__ void tcgen05_mma(uint32_t tmem_addr,
-                             uint64_t desc_a, uint64_t desc_b,
-                             uint32_t idesc_c, uint32_t idesc_d) {
-    asm volatile(
-        "tcgen05.mma.cta_group::1.kind::f16"
-        " %0, %1, %2, %3, %4;"
-        :: "r"(tmem_addr), "l"(desc_a), "l"(desc_b),
-           "r"(idesc_c), "r"(idesc_d)
-    );
-}
-
-// Load TMEM to registers
-__device__ void tmem_load(float* dst, uint32_t tmem_addr, int cols) {
-    asm volatile(
-        "tcgen05.ld.sync.aligned.32x32b.x1 {%0}, [%1];"
-        : "=r"(*dst) : "r"(tmem_addr)
-    );
-}
-
-// Deallocate TMEM (MUST do before kernel exit)
-__device__ void tmem_dealloc(uint32_t addr, uint32_t num_cols) {
-    asm volatile(
-        "tcgen05.dealloc.cta_group::1.sync.aligned %0, %1;"
-        :: "r"(addr), "r"(num_cols)
-    );
-}
-```
-
-## mbarrier Synchronization
-
-```cuda
-// TMA-MMA synchronization via mbarrier
-// expected_bytes: total bytes the TMA will deliver to this stage
-__device__ void mbarrier_arrive(uint64_t* mbar, uint32_t expected_bytes) {
-    asm volatile(
-        "mbarrier.arrive.expect_tx.shared.b64 _, [%0], %1;"
-        :: "r"((uint32_t)__cvta_generic_to_shared(mbar)),
-           "r"(expected_bytes)
-    );
-}
-
-__device__ void mbarrier_wait(uint64_t* mbar, int phase) {
-    asm volatile(
-        "{\n"
-        ".reg .pred p;\n"
-        "WAIT_LOOP:\n"
-        "  mbarrier.try_wait.parity.shared.b64 p, [%0], %1;\n"
-        "  @!p bra WAIT_LOOP;\n"
-        "}\n"
-        :: "r"((uint32_t)__cvta_generic_to_shared(mbar)),
-           "r"(phase)
-    );
-}
-```
-
-## Warp Role Dispatch
-
-```cuda
-__global__ void blackwell_gemm_kernel(...) {
-    int warp_id = threadIdx.x / 32;
-    int lane_id = threadIdx.x % 32;
-
-    if (warp_id == 0 && lane_id == 0) {
-        // TMA producer: issue cp.async.bulk.tensor
-        tma_producer_loop(...);
-    } else if (warp_id == 1 && lane_id == 0) {
-        // MMA consumer: issue tcgen05.mma
-        mma_consumer_loop(...);
-    } else if (warp_id >= 2) {
-        // Epilogue: read TMEM, write to global
-        epilogue_loop(...);
-    }
-}
-```
-
-## Related
-- [ptx-sm100](ptx-sm100.md) — PTX instruction reference
-- [tcgen05 tutorial](../../../sources/blogs/tcgen05-tutorial.md) — Step-by-step guide

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/nvidia/languages/cute-dsl.md

@@ -1,121 +0,0 @@
----
-id: lang-cute-dsl
-title: "CuTe DSL for Blackwell"
-type: language
-tags: [cute-dsl, tcgen05, tmem, tma]
-related: [hw-tcgen05-mma, hw-tmem, kernel-flash-attention-4, doc-cutlass-blackwell]
-sources: [doc-cutlass-blackwell, blog-colfax-cutlass, blog-flash-attention-4]
-reproducibility: snippet
-architectures: [sm100, sm100a]
-languages:
-- cute-dsl
-confidence: source-reported
-evidence_level: spec
----
-
-## Overview
-
-CuTe (CUDA Templates) DSL is the primary abstraction layer in CUTLASS 4.5.0 for Blackwell kernels. FlashAttention-4 was implemented entirely in CuTe-DSL (Python variant), achieving 20-30× faster compilation than C++ templates.
-
-## SM100 MMA Atoms
-
-```python
-# CuTe-DSL: SM100 MMA atom for BF16
-from cutlass.cute import *
-
-# 1-SM MMA: m128 x n256 x k16
-mma_atom = SM100_MMA_F16BF16_SS  # inputs from shared memory
-# Accumulator goes to TMEM automatically
-
-# 2-SM MMA: m256 x n256 x k16
-mma_atom_2sm = SM100_MMA_F16BF16_SS_2SM
-```
-
-## TMEM as CuTe Locale
-
-```python
-# TMEM allocation in CuTe
-tmem_tensor = make_tensor(
-    make_tmem_ptr(tmem_addr),
-    make_layout(make_shape(128, 256))  # rows x cols
-)
-
-# Copy TMEM → registers for epilogue
-copy(tmem_tensor, reg_tensor)  # tcgen05.ld under the hood
-```
-
-## TMA Copy Atoms
-
-```python
-# TMA bulk copy: global → shared
-tma_copy = SM100_TMA_LOAD_2D
-
-# Setup TMA descriptor
-tma_desc = make_tma_copy(
-    tma_copy,
-    global_tensor,
-    smem_layout,
-    tile_shape,
-    cluster_shape
-)
-```
-
-## Warp-Specialized Kernel Skeleton
-
-```python
-@cute_kernel
-def blackwell_gemm(A, B, C):
-    # Warp 0: TMA producer
-    if warp_id == 0:
-        for stage in pipeline:
-            tma_copy(A_tile, smem_A[stage])
-            tma_copy(B_tile, smem_B[stage])
-            arrive(mbarrier[stage])
-
-    # Warp 1: MMA consumer
-    elif warp_id == 1:
-        tmem = alloc_tmem(256)  # columns
-        for stage in pipeline:
-            wait(mbarrier[stage])
-            fence_after_thread_sync()
-            mma(smem_A[stage], smem_B[stage], tmem)
-        signal_epilogue()
-
-    # Warps 2+: Epilogue
-    else:
-        wait_epilogue()
-        regs = load_tmem(tmem)
-        store_global(C, regs)
-        dealloc_tmem(tmem)
-```
-
-## Why CuTe-DSL for Blackwell
-
-1. **20-30× faster compilation** than C++ CUTLASS templates
-2. Python-native: easier to iterate and debug
-3. Same performance as hand-written C++ (FlashAttention-4: 1605 TFLOPS)
-4. First-class TMEM and tcgen05 support in CUTLASS 4.5.0
-5. Automatic layout computation and swizzle handling
-
-## Full Examples (verbatim upstream code shipped locally)
-
-The following CuTe DSL files ship **verbatim** in this repository under `artifacts/prs/cutlass/` (pinned at each PR's merge SHA). Open them with `python3 scripts/get_page.py <pr-id> --include-code` or read them directly.
-
-| File | Purpose | Size |
-|---|---|---|
-| [`artifacts/prs/cutlass/PR-3106/key-files/examples/python/CuTeDSL/blackwell/tutorial_gemm/fp16_gemm_0.py`](../../../artifacts/prs/cutlass/PR-3106/key-files/examples/python/CuTeDSL/blackwell/tutorial_gemm/fp16_gemm_0.py) | Step 0 — FP16 GEMM baseline | 447 lines |
-| [`artifacts/prs/cutlass/PR-3106/key-files/examples/python/CuTeDSL/blackwell/tutorial_gemm/fp16_gemm_1.py`](../../../artifacts/prs/cutlass/PR-3106/key-files/examples/python/CuTeDSL/blackwell/tutorial_gemm/fp16_gemm_1.py) | Step 1 — 2CTA MMA + TMA multicast | 535 lines |
-| [`artifacts/prs/cutlass/PR-3106/key-files/examples/python/CuTeDSL/blackwell/tutorial_gemm/fp16_gemm_2.py`](../../../artifacts/prs/cutlass/PR-3106/key-files/examples/python/CuTeDSL/blackwell/tutorial_gemm/fp16_gemm_2.py) | Step 2 — Warp specialization (TMA / MMA / epilogue warps) | 679 lines |
-| [`artifacts/prs/cutlass/PR-3106/key-files/examples/python/CuTeDSL/blackwell/tutorial_gemm/fp16_gemm_3.py`](../../../artifacts/prs/cutlass/PR-3106/key-files/examples/python/CuTeDSL/blackwell/tutorial_gemm/fp16_gemm_3.py) | Step 3 — Static persistent tile scheduler | 769 lines |
-| [`artifacts/prs/cutlass/PR-3106/key-files/examples/python/CuTeDSL/blackwell/tutorial_gemm/fp16_gemm_4.py`](../../../artifacts/prs/cutlass/PR-3106/key-files/examples/python/CuTeDSL/blackwell/tutorial_gemm/fp16_gemm_4.py) | Step 4 — Preferred + dynamic clusters | 1065 lines |
-| [`artifacts/prs/cutlass/PR-3106/key-files/examples/python/CuTeDSL/blackwell/tutorial_gemm/fp16_gemm_5.py`](../../../artifacts/prs/cutlass/PR-3106/key-files/examples/python/CuTeDSL/blackwell/tutorial_gemm/fp16_gemm_5.py) | Step 5 — TMA prefetch | 919 lines |
-| [`artifacts/prs/cutlass/PR-3106/key-files/examples/python/CuTeDSL/blackwell/tutorial_gemm/fp16_gemm_6.py`](../../../artifacts/prs/cutlass/PR-3106/key-files/examples/python/CuTeDSL/blackwell/tutorial_gemm/fp16_gemm_6.py) | Step 6 — Programmatic Dependent Launch (PDL) | 1002 lines |
-| [`artifacts/prs/cutlass/PR-2881/key-files/examples/python/CuTeDSL/blackwell/dense_gemm_persistent_prefetch.py`](../../../artifacts/prs/cutlass/PR-2881/key-files/examples/python/CuTeDSL/blackwell/dense_gemm_persistent_prefetch.py) | Persistent GEMM with prefetch | full |
-| [`artifacts/prs/cutlass/PR-3021/key-files/python/CuTeDSL/cutlass/cute/arch/clc.py`](../../../artifacts/prs/cutlass/PR-3021/key-files/python/CuTeDSL/cutlass/cute/arch/clc.py) | CLC (Cluster Launch Control) Python binding | full |
-
-The `fp16_gemm_{0..6}.py` series from `examples/python/CuTeDSL/blackwell/tutorial_gemm/` in NVIDIA/cutlass PR-3106 is the authoritative CuTe DSL learning path: it walks from a naive FP16 GEMM baseline through 2CTA MMA with TMA multicast, warp specialization, static persistent scheduling, preferred / dynamic clusters, TMA prefetch, and ends with Programmatic Dependent Launch (PDL). Reading them in order is the recommended on-ramp.
-
-## Related
-- [tcgen05-mma](../hardware/tcgen05-mma.md) — Underlying MMA instruction
-- [flash-attention-4](../kernels/flash-attention-4.md) — CuTe-DSL implementation
-- [CUTLASS Blackwell docs](../../../sources/docs/nvidia-cutlass-blackwell.md) — Official reference