@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/hardware/ldmatrix/pitfalls-ldmatrix-ptx.md

@@ -1,73 +0,0 @@
----
-id: pitfall-ldmatrix-ptx
-type: pitfall
-vendor: nvidia
-title: Pitfalls
-architectures:
-- sm90
-- sm90a
-languages:
-- ptx
-- cuda-cpp
-hardware_features:
-- wgmma
-- tma
-- ldmatrix
-techniques:
-- pipeline-stages
-- shared-memory-optimization
-kernel_types:
-- gemm
-confidence: inferred
-evidence_level: inferred
-tags:
-- wgmma
-- tma
-- ldmatrix
-- pipeline-stages
-- shared-memory-optimization
-- gemm
-- ptx
-- cuda-cpp
----
-# ldmatrix Pitfalls
-
-## 1. Smem alignment requirement
-
-**Problem**: `ldmatrix.sync.aligned` requires the shared memory pointer to be 16-byte aligned. Misaligned addresses cause undefined behavior or a hardware trap (illegal memory access).
-
-**Trigger**: Allocating smem with arbitrary byte offset, or computing a row pointer that is not 16-byte aligned due to non-power-of-2 row strides.
-
-**Mitigation**: Ensure smem allocation is 16-byte aligned (the default for `__shared__` arrays is typically sufficient). When computing per-thread smem addresses, verify that `(address & 0xF) == 0`.
-
-## 2. Transposed vs non-transposed confusion
-
-**Problem**: Using `ldmatrix.sync.aligned.x4.m8n8` (non-transposed) to load the B operand for a `.row.col` mma.sync, when B needs to be in column-major (transposed) layout. The resulting register contents have the wrong element mapping, causing silent data corruption.
-
-**Trigger**: Not matching the ldmatrix variant to the mma.sync operand layout convention. For `mma.sync...row.col`, A is row-major (use non-transposed ldmatrix) and B is col-major (use transposed ldmatrix).
-
-**Mitigation**: Follow the cutlass convention: A uses `SM75_U32x4_LDSM_N` (non-transposed), B uses `SM75_U16x4_LDSM_T` (transposed) for the standard TN layout. Test with known-answer inputs.
-
-## 3. Per-thread address must point to the thread's own row
-
-**Problem**: All 32 threads in the warp execute ldmatrix simultaneously, and each thread provides its own smem address. The hardware gathers from all 32 addresses to fill the matrix fragment. If a thread provides a wrong address (e.g., all threads provide the same address), the fragment is filled with repeated data from one row.
-
-**Trigger**: Using a broadcast address like `smem_base` instead of `smem_base + lane_id * row_stride`.
-
-**Mitigation**: Compute per-thread addresses carefully. For an 8x8 tile of fp16 in row-major: `smem_ptr = smem_base + (lane_id % 8) * row_stride_bytes`. The first 8 lanes cover the first tile's 8 rows; lanes 8-15 cover the second tile, etc.
-
-## 4. Incompatible with wgmma on Hopper
-
-**Problem**: On Hopper, using ldmatrix to feed wgmma is unnecessary and inefficient. wgmma in SS mode reads operands directly from smem via descriptors. wgmma in RS mode expects A fragments in a different register layout than what ldmatrix produces.
-
-**Trigger**: Porting Ampere kernel patterns (ldmatrix → mma.sync) to Hopper without switching to the TMA → wgmma pipeline.
-
-**Mitigation**: On Hopper, use TMA to fill smem and wgmma.mma_async with smem descriptors (SS mode). Only fall back to ldmatrix if the kernel must use mma.sync for backward compatibility.
-
-## 5. Register count mismatch between x1/x2/x4 and the mma variant
-
-**Problem**: Loading with `ldmatrix.x1` (1 register per thread) but the mma.sync variant expects x4 (4 registers per thread for the A operand of m16n8k16). The mma.sync reads uninitialized register contents for the missing fragments.
-
-**Trigger**: Mismatching the ldmatrix variant with the mma.sync K-dimension. m16n8k8 needs x2 for A; m16n8k16 needs x4 for A.
-
-**Mitigation**: Always match: `mma.sync.m16n8k8` pairs with `ldmatrix.x2` for A and `ldmatrix.x1` for B; `mma.sync.m16n8k16` pairs with `ldmatrix.x4` for A and `ldmatrix.x2` for B. Consult the PTX ISA fragment tables.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/nvidia/hardware/ldmatrix/skill-ldmatrix-ptx.md

@@ -1,117 +0,0 @@
----
-title: 'ldmatrix: Shared-memory to register matrix load for tensor cores'
-status: draft
-evidence_level: spec
-applies_to_pattern_class:
-- tensor-core
-applies_to_ops:
-- gemm
-- attention
-requires_sm: '>=7.5'
-requires_features:
-- ldmatrix
-single_kernel_useful: true
-source:
-- path: spec
-  anchor: Reference
-related_apis: []
-related_skills:
-- mma-sync-ptx
-- wgmma-ptx
-upstream_repo: cutlass@f74fea9c
-id: skill-ldmatrix-ptx
-type: skill
-vendor: nvidia
-tags:
-- cuda-cpp
-- wgmma
-- tma
-- ldmatrix
-- shared-memory-optimization
-- gemm
-- attention
-- ptx
-- cute-dsl
-applies_to:
-- general
-source_refs:
-- source_id: source-code/cutlass
-  path: include/cute/atom/copy_traits_sm75.hpp
-  anchor: SM75_U32x1_LDSM_N .. SM75_U16x8_LDSM_T
-- source_id: source-code/cutlass
-  path: include/cute/arch/copy_sm75.hpp
-  anchor: ldmatrix PTX wrappers
-- source_id: cuda-official/toolkit-docs-13.2
-  path: CUDA Programming Guides/parallel-thread-execution/cuda_parallel-thread-execution_index.html.md
-  anchor: L27850-L27890
-architectures:
-- sm90
-- sm90a
-languages:
-- ptx
-- cuda-cpp
-- cute-dsl
-hardware_features:
-- wgmma
-- tma
-- ldmatrix
-techniques:
-- shared-memory-optimization
-kernel_types:
-- gemm
-- attention
-confidence: source-reported
----
-# ldmatrix — Shared-memory to register matrix load for tensor cores
-
-## What it is
-
-`ldmatrix` is a warp-level instruction (sm_75+, Turing and later) that loads 8x8 matrix tiles from shared memory into registers, distributing fragments across the 32 threads of a warp in the exact layout that `mma.sync` expects. It replaces the manual "load from smem + cross-lane shuffle" pattern with a single hardware instruction.
-
-The instruction comes in two variants:
-- **Non-transposed** (`ldmatrix.sync.aligned.x{1,2,4}.m8n8.shared.b16`): loads 1, 2, or 4 contiguous 8x8 tiles without transposition.
-- **Transposed** (`ldmatrix.sync.aligned.x{1,2,4}.m8n8.trans.shared.b16`): loads with an implicit transpose, useful for the B operand in TN layout.
-
-In cutlass-cute, these are wrapped as:
-- `SM75_U32x1_LDSM_N`, `SM75_U32x2_LDSM_N`, `SM75_U32x4_LDSM_N` (non-transposed)
-- `SM75_U16x2_LDSM_T`, `SM75_U16x4_LDSM_T`, `SM75_U16x8_LDSM_T` (transposed)
-
-A companion instruction, `movmatrix` (`SM75_U32x1_MOVM_T`), transposes a matrix already in registers.
-
-## PTX mnemonic template
-
-```asm
-// Load 4 × 8x8 tiles (the most common variant for m16n8k16):
-ldmatrix.sync.aligned.x4.m8n8.shared.b16
-    {%r0, %r1, %r2, %r3},   // 4 uint32 destination registers per thread
-    [smem_ptr];               // shared memory address (each thread provides its row's address)
-```
-
-Each thread in the warp provides the smem address for its own row's 8-element strip. The hardware performs a cross-lane gather so that the resulting register contents match what `mma.sync` expects.
-
-## Variants
-
-| Variant | PTX suffix | Tiles loaded | Regs/thread | cute atom |
-|---|---|---|---|---|
-| x1 non-transposed | `.x1.m8n8` | 1 × 8x8 | 1 × uint32 | `SM75_U32x1_LDSM_N` |
-| x2 non-transposed | `.x2.m8n8` | 2 × 8x8 | 2 × uint32 | `SM75_U32x2_LDSM_N` |
-| x4 non-transposed | `.x4.m8n8` | 4 × 8x8 | 4 × uint32 | `SM75_U32x4_LDSM_N` |
-| x2 transposed | `.x2.m8n8.trans` | 2 × 8x8 (transposed) | 2 × uint16 pairs | `SM75_U16x2_LDSM_T` |
-| x4 transposed | `.x4.m8n8.trans` | 4 × 8x8 (transposed) | 4 × uint16 pairs | `SM75_U16x4_LDSM_T` |
-| x8 transposed | `.x8.m8n8.trans` | 8 × 8x8 (transposed) | 8 × uint16 pairs | `SM75_U16x8_LDSM_T` |
-
-## When to use it
-
-- Loading A/B operands for `mma.sync` on Ampere (sm_80+). ldmatrix handles the smem→register layout mapping that mma.sync requires.
-- On Turing (sm_75) / Volta for older MMA instructions.
-
-## When NOT to use it
-
-- On Hopper with wgmma in SS mode: wgmma reads A and B directly from smem via descriptors — no ldmatrix needed. The RS variant of wgmma uses register-resident A but still does not use ldmatrix (the agent must fill the A fragment layout manually or via TMA → register staging).
-- When the smem layout is incompatible with ldmatrix's 16-byte alignment requirement.
-
-## How it connects to the rest of the KB
-
-- Required companion to `wiki/nvidia/hardware/mma-sync-ptx/` — mma.sync expects fragments in ldmatrix's output layout.
-- Superseded on Hopper by TMA + smem descriptors for the wgmma path.
-- cutlass-cute wraps ldmatrix in `Copy_Traits<SM75_U32x{1,2,4}_LDSM_N>` (see `copy_traits_sm75.hpp`).

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

@@ -1,103 +0,0 @@
----
-id: hw-mbarrier
-title: mbarrier (Memory Barrier Primitives)
-type: hardware
-architectures:
-- sm100
-- sm100a
-- sm90
-- sm90a
-languages:
-- '*'
-tags:
-- mbarrier
-- tma
-confidence: source-reported
-evidence_level: spec
-related:
-- hw-tma
-- hw-tcgen05-mma
-- technique-warp-specialization
-- technique-pipeline-stages
-sources:
-- doc-ptx-isa-sm100
-- blog-tcgen05-tutorial
-- doc-nvidia-tuning-guide
-aliases:
-- mbarrier
-- memory barrier
-- mbar
----
-# mbarrier
-
-## Overview
-
-mbarriers are 64-bit shared memory primitives used for producer/consumer synchronization between asynchronous hardware units (TMA, tcgen05) and SM threads. Introduced on Hopper, essential for Blackwell warp-specialized kernels.
-
-## Key Operations
-
-```ptx
-// Initialize: set expected arrival count
-mbarrier.init.shared.b64 [mbar_addr], num_arrivals;
-
-// Producer: arrive on barrier (decrements expected count)
-mbarrier.arrive.shared.b64 _, [mbar_addr];
-
-// Producer (with byte expectation): used by TMA
-mbarrier.arrive.expect_tx.shared.b64 _, [mbar_addr], expected_bytes;
-// After this, TMA hardware completes the transaction by arriving with
-// the transferred byte count, and the mbarrier flips parity.
-
-// Consumer: wait for parity flip
-mbarrier.try_wait.parity.shared.b64 p, [mbar_addr], phase;
-@!p bra WAIT_LOOP;
-```
-
-## Phase/Parity Semantics
-
-mbarriers have a 1-bit **phase** that flips each time the arrival count reaches zero. Consumers track their expected phase and wait for it:
-
-```cuda
-int phase = 0;
-for (int k = 0; k < num_iterations; k++) {
-    int stage = k % NUM_STAGES;
-
-    // Wait for this stage's producer to complete
-    mbarrier_wait_parity(&mbar[stage], phase);
-    phase ^= 1;  // Flip for next use of this stage slot
-
-    // Use data...
-    consume_data(stage);
-
-    // Arrive on next-stage barrier when done
-    mbarrier_arrive(&buffer_free[stage]);
-}
-```
-
-## TMA Integration
-
-TMA directly signals mbarriers when transfer completes, avoiding manual polling:
-
-```cuda
-// Producer warp issues TMA with mbarrier target
-if (lane_id == 0) {
-    uint32_t tx_bytes = TILE_A_BYTES + TILE_B_BYTES;
-    mbarrier_arrive_expect_tx(&mbar[stage], tx_bytes);
-
-    // TMA completion will fire the mbarrier automatically
-    cp_async_bulk_tensor_2d(smem_A[stage], global_desc, x, y, &mbar[stage]);
-    cp_async_bulk_tensor_2d(smem_B[stage], global_desc, x, y, &mbar[stage]);
-}
-// Do NOT manually arrive after TMA issue - it races with hardware
-```
-
-## Pitfalls
-
-1. **Missing phase flip**: Reusing a stage slot without flipping parity causes stale arrivals to satisfy the new wait
-2. **Mismatched init count**: If consumer expects N arrivals but producers only arrive M times, barrier never fires
-3. **Manual arrive after async issue**: TMA/tcgen05 hardware arrives on completion — extra manual arrive causes double-count
-4. **Cross-cluster mbarriers**: Use `shared::cluster` qualifier for cluster-level sync (2-SM cooperative MMA)
-
-## Related
-- [TMA](tma.md) — Primary producer for mbarriers
-- [warp-specialization](../techniques/warp-specialization.md) — Uses mbarriers for warp role handoff

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/nvidia/hardware/mma-sync/pitfalls-mma-sync-ptx.md

@@ -1,69 +0,0 @@
----
-id: pitfall-mma-sync-ptx
-type: pitfall
-vendor: nvidia
-title: Pitfalls
-architectures:
-- sm90
-- sm90a
-languages:
-- ptx
-- cuda-cpp
-hardware_features:
-- wgmma
-- ldmatrix
-techniques:
-- shared-memory-optimization
-kernel_types:
-- gemm
-confidence: inferred
-evidence_level: inferred
-tags:
-- wgmma
-- ldmatrix
-- shared-memory-optimization
-- gemm
-- ptx
-- cuda-cpp
----
-# mma.sync Pitfalls
-
-## 1. Fragment layout mismatch
-
-**Problem**: The per-thread register layout for mma.sync operands (A, B, C/D) follows a non-obvious mapping described in the PTX ISA. Packing fp16 values into uint32 registers in the wrong order produces silently incorrect results.
-
-**Trigger**: Manually filling A/B register fragments without using `ldmatrix` or cutlass's `copy_atom` to handle the layout mapping.
-
-**Mitigation**: Always use `ldmatrix` to load A/B from shared memory — it handles the smem-to-register transpose that mma.sync expects. If manual packing is unavoidable, consult the PTX ISA section "Matrix Fragments for mma.m16n8k16" and test with known-answer inputs (e.g., identity-matrix × vector).
-
-## 2. Convergent warp required
-
-**Problem**: `mma.sync` is a warp-synchronous instruction. If threads within the warp have diverged (e.g., via data-dependent `if` statements), the instruction will hang or produce undefined behavior.
-
-**Trigger**: Calling mma.sync from within a branch that not all 32 threads in the warp take.
-
-**Mitigation**: Ensure all 32 threads in the warp reach the mma.sync instruction. Use `__syncwarp()` if convergence is in doubt, or restructure the control flow so the mma.sync is on the converged path.
-
-## 3. Alignment and dtype requirements
-
-**Problem**: The A and B operands must be in the exact register types the instruction expects. For `mma.sync.aligned.m16n8k16.row.col.f32.f16.f16.f32`, A must be 4 × uint32 (8 packed fp16), B must be 2 × uint32 (4 packed fp16). Passing the wrong number of registers causes a ptxas compile error; passing the right count but wrong dtype causes silent corruption.
-
-**Trigger**: Mixing up the single-K (m16n8k8, 2 A-registers) and double-K (m16n8k16, 4 A-registers) variants, or using bf16 data with an f16 instruction variant.
-
-**Mitigation**: Match the mnemonic suffix exactly: `.f16.f16` requires fp16 data in the registers, `.bf16.bf16` requires bf16. Use cutlass's `MMA_Traits` struct to derive the correct fragment counts: `FrgTypeA`, `FrgTypeB`, `FrgTypeC`, `FrgTypeD`.
-
-## 4. Confusing mma.sync with wgmma
-
-**Problem**: Writing a Hopper kernel that uses mma.sync instead of wgmma. mma.sync works on Hopper (sm_90a) but wastes the wgmma issue port — one mma.sync covers m16n8k16 per warp (32 threads), while one wgmma covers m64n128k16 per warpgroup (128 threads). Throughput can be 8-16x lower.
-
-**Trigger**: Porting Ampere code to Hopper without migrating from mma.sync to wgmma.
-
-**Mitigation**: On sm_90a, always prefer wgmma. Reserve mma.sync for backward-compatibility paths or operators that structurally cannot use warpgroup-level instructions.
-
-## 5. Missing ldmatrix before mma.sync
-
-**Problem**: mma.sync expects A and B fragments in a specific register layout that differs from a naive smem load. Using simple `__shfl_sync` or direct `smem[tid]` loads places data in the wrong register positions.
-
-**Trigger**: Loading A/B from smem via `smem[thread_offset]` into registers and passing to mma.sync without the ldmatrix transpose.
-
-**Mitigation**: Use `ldmatrix` (see `wiki/nvidia/hardware/ldmatrix-ptx/skill.md`) to load from smem — it performs the cross-lane shuffle needed by mma.sync in hardware.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/nvidia/hardware/mma-sync/skill-mma-sync-ptx.md

@@ -1,122 +0,0 @@
----
-title: 'mma.sync: Warp-level MMA on Ampere+ via PTX'
-status: draft
-evidence_level: spec
-applies_to_pattern_class:
-- tensor-core
-applies_to_ops:
-- gemm
-- attention
-requires_sm: '>=8.0'
-requires_features:
-- mma.sync
-- ldmatrix
-single_kernel_useful: true
-source:
-- path: spec
-  anchor: Reference
-related_apis: []
-related_skills:
-- wgmma
-- wgmma-ptx
-- ldmatrix-ptx
-upstream_repo: cutlass@f74fea9c
-id: skill-mma-sync-ptx
-type: skill
-vendor: nvidia
-tags:
-- cuda-cpp
-- wgmma
-- tma
-- ldmatrix
-- shared-memory-optimization
-- gemm
-- attention
-- ptx
-- cute-dsl
-applies_to:
-- general
-source_refs:
-- source_id: source-code/cutlass
-  path: include/cute/atom/mma_traits_sm80.hpp
-  anchor: SM80_16x8x8_F32F16F16F32_TN .. SM80_16x8x32_S32S8S8S32_TN
-- source_id: source-code/cutlass
-  path: include/cute/arch/mma_sm80.hpp
-  anchor: SM80_16x8x8_F32F16F16F32_TN inline PTX wrappers
-- source_id: cuda-official/toolkit-docs-13.2
-  path: CUDA Programming Guides/parallel-thread-execution/cuda_parallel-thread-execution_index.html.md
-  anchor: L28200-L28250
-architectures:
-- sm90
-- sm90a
-languages:
-- ptx
-- cuda-cpp
-- cute-dsl
-hardware_features:
-- wgmma
-- tma
-- ldmatrix
-techniques:
-- shared-memory-optimization
-kernel_types:
-- gemm
-- attention
-confidence: source-reported
----
-# mma.sync — Warp-level MMA on Ampere+ via PTX
-
-## What it is
-
-`mma.sync` is the Ampere-era (sm_80+) warp-level matrix-multiply-accumulate instruction. Unlike Hopper's wgmma (which operates at warpgroup granularity = 128 threads), `mma.sync` is a **single-warp** (32 threads) synchronous instruction. Each `mma.sync` call computes a small tile (typically m16n8k8 for fp16/bf16 or m16n8k16 for the double-K variant) and returns immediately — there is no asynchronous issue/commit/wait protocol.
-
-In cutlass-cute the atoms live in `MMA_Traits<SM80_16x8x{K}_{Acc}{A}{B}{Acc}_TN>` structs inside `mma_traits_sm80.hpp`.
-
-## Atom shapes supported on Ampere (sm_80+)
-
-| Family | M | N | K | Acc dtype | Input dtypes | cute atom struct |
-|---|---|---|---|---|---|---|
-| F16/BF16 → F16 | 16 | 8 | 8 | f16 | f16×f16 | `SM80_16x8x8_F16F16F16F16_TN` |
-| F16/BF16 → F16 (double-K) | 16 | 8 | 16 | f16 | f16×f16 | `SM80_16x8x16_F16F16F16F16_TN` |
-| F16 → F32 | 16 | 8 | 8 | f32 | f16×f16 | `SM80_16x8x8_F32F16F16F32_TN` |
-| F16 → F32 (double-K) | 16 | 8 | 16 | f32 | f16×f16 | `SM80_16x8x16_F32F16F16F32_TN` |
-| BF16 → F32 | 16 | 8 | 8 | f32 | bf16×bf16 | `SM80_16x8x8_F32BF16BF16F32_TN` |
-| BF16 → F32 (double-K) | 16 | 8 | 16 | f32 | bf16×bf16 | `SM80_16x8x16_F32BF16BF16F32_TN` |
-| TF32 → F32 | 16 | 8 | 4 | f32 | tf32×tf32 | `SM80_16x8x4_F32TF32TF32F32_TN` |
-| TF32 → F32 (double-K) | 16 | 8 | 8 | f32 | tf32×tf32 | `SM80_16x8x8_F32TF32TF32F32_TN` |
-| F64 → F64 | 8 | 8 | 4 | f64 | f64×f64 | `SM80_8x8x4_F64F64F64F64_TN` |
-| S8 → S32 | 8/16 | 8 | 16/32 | s32 | s8×s8 | `SM80_8x8x16_S32S8S8S32_TN` / `SM80_16x8x16_S32S8S8S32_TN` / `SM80_16x8x32_S32S8S8S32_TN` |
-| Mixed S8/U8 → S32 | 8/16 | 8 | 16/32 | s32 | s8×u8 / u8×s8 | `SM80_*_S32S8U8S32_TN` / `SM80_*_S32U8S8S32_TN` |
-
-## PTX mnemonic template
-
-```asm
-mma.sync.aligned.m16n8k16.row.col.f32.f16.f16.f32
-    {%f0, %f1, %f2, %f3},       // 4 f32 accumulators per thread
-    {%r0, %r1, %r2, %r3},       // 4 uint32 registers holding A fragment (8 fp16 values packed)
-    {%r4, %r5},                  // 2 uint32 registers holding B fragment (4 fp16 values packed)
-    {%f4, %f5, %f6, %f7};       // 4 f32 source accumulators (C for D = A*B + C)
-```
-
-Key differences from wgmma:
-- **Synchronous**: no fence/commit/wait; result is in registers immediately after the instruction retires.
-- **Per-warp**: 32 threads, not 128 (warpgroup).
-- **Register-resident operands**: A and B are in registers (typically loaded via `ldmatrix`), not in smem descriptors.
-- **Multiple issues needed**: to cover an M=64 tile a kernel must issue 4 consecutive m16n8k16 calls (one per 16-row slice), versus one wgmma.mma_async for the whole M=64 tile on Hopper.
-
-## When to use it
-
-- Targets sm_80 / sm_86 / sm_89 (Ampere / Ada Lovelace) where wgmma is not available.
-- Porting legacy Ampere kernels to understand the hardware before migrating to Hopper wgmma.
-- Operators on Hopper that cannot use wgmma (e.g. blocks with fewer than 128 threads).
-
-## When NOT to use it
-
-- On Hopper (sm_90a): use wgmma instead. wgmma covers the entire warpgroup in one instruction and pairs with TMA for higher throughput.
-- When you can use cutlass's `TiledMMA<MMA_Atom<SM80_*>>` abstraction instead of raw PTX.
-
-## How it connects to the rest of the KB
-
-- Predecessor to `wiki/nvidia/hardware/wgmma-ptx/` — wgmma replaces mma.sync on Hopper with warpgroup-level granularity and an async issue model.
-- Pairs with `wiki/nvidia/hardware/ldmatrix-ptx/` — ldmatrix loads A/B fragments from smem into registers in the layout mma.sync expects.
-- cutlass-cute wraps mma.sync in `MMA_Atom<MMA_Traits<SM80_*>>` (see `mma_traits_sm80.hpp`).

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

@@ -1,62 +0,0 @@
----
-id: hw-nvfp4
-title: "NVFP4 and Block-Scaled Narrow Precision"
-type: hardware
-architectures: [sm100, sm100a]
-languages:
-- '*'
-tags: [nvfp4, fp4, block-scale, fp8, fp6]
-confidence: source-reported
-evidence_level: spec
-related: [technique-fine-grained-quantization, kernel-nvfp4-gemm, kernel-nvfp4-gemv, hw-tcgen05-mma]
-sources: [doc-nvidia-tuning-guide, contest-gpumode-p1, contest-gpumode-p2, blog-yue-nvfp4]
-aliases: [NVFP4, E2M1, "FP4 E2M1", "nv_float4"]
----
-
-## Overview
-
-NVFP4 is NVIDIA's 4-bit floating-point format (E2M1) with block scaling, native to Blackwell tensor cores.
-
-## Format Details
-
-```
-E2M1: 1 sign bit, 2 exponent bits, 1 mantissa bit
-Representable values: 0, ±0.5, ±1, ±1.5, ±2, ±3, ±4, ±6
-
-Block scaling: every 16 FP4 elements share one FP8 E4M3 scale factor
-Two-level: per-block E4M3 scale × per-tensor FP32 global scale
-
-Quantization:   q_i = cast_FP4(x_i / (s_global * s_block))
-Dequantization: x_hat_i = s_global * s_block * deq_FP4(q_i)
-```
-
-## tcgen05 Variants for FP4
-
-| Variant | Description | Throughput vs Hopper |
-|---|---|---|
-| `tcgen05.mma.mxf4.block_scale` | MX FP4 with block scaling | **4×** |
-| `tcgen05.mma.mxf4nvf4.block_scale` | NVFP4 + MX FP4 flexible scaling | **4×** |
-
-## PTX for FP4 Conversion
-
-```ptx
-// Convert two FP4 values to two FP16 values
-cvt.rn.f16x2.e2m1x2 result, packed_fp4;
-
-// Byte unpacking (faster than bitwise extraction)
-mov.b32 {tmp0, tmp1, tmp2, tmp3}, packed_data;
-```
-
-## NVFP4 vs MXFP4
-
-| Aspect | NVFP4 | MXFP4 |
-|---|---|---|
-| Scale format | E4M3 (fractional) | UE8M0 (power-of-2 only) |
-| Block size | 16 elements | 32 elements |
-| Scale precision | Non-power-of-2 | Power-of-2 only |
-| Quantization error | Lower | Higher |
-
-## Related
-- [fine-grained-quantization](../techniques/fine-grained-quantization.md) — Scaling strategies
-- [nvfp4-gemm](../kernels/nvfp4-gemm.md) — NVFP4 GEMM kernel
-- [nvfp4-gemv](../kernels/nvfp4-gemv.md) — NVFP4 GEMV kernel

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/nvidia/hardware/pdl-gdc.md

@@ -1,57 +0,0 @@
----
-id: hw-pdl-gdc
-title: Programmatic Dependent Launch / Grid Dependency Control
-type: hardware
-architectures:
-- sm100
-- sm100a
-- sm90
-languages:
-- '*'
-tags:
-- pdl
-- gdc
-confidence: source-reported
-evidence_level: spec
-related:
-- technique-persistent-kernels
-- hw-clc
-sources:
-- doc-nvidia-tuning-guide
-- pr-cutlass-2161
-- doc-cutlass-changelog-sm100
-aliases:
-- PDL
-- GDC
-- programmatic dependent launch
-- grid dependency control
----
-## Overview
-
-PDL/GDC allows overlapping execution of dependent kernel launches. The primary kernel signals it is finishing; the secondary kernel begins before the primary fully completes.
-
-## How It Works
-
-```cuda
-// Primary kernel signals near completion
-cudaGridDependencySynchronize();  // or PTX equivalent
-
-// Secondary kernel can start overlapping with primary's tail
-// Enabled by default on SM100 (opt-in on SM90)
-```
-
-## Blackwell Default Behavior
-
-On SM100, PDL is **enabled by default** — no opt-in needed. This means:
-- Back-to-back kernel launches naturally overlap
-- Memory fences ensure correctness for dependent data
-- Reduces kernel launch gaps in compute-heavy pipelines
-
-## When It Matters
-- Chains of small kernels (e.g., MoE dispatch → compute → combine)
-- Pipeline-parallel training with many sequential kernel launches
-- Reduces overall wall-clock time without code changes on Blackwell
-
-## Related
-- [persistent-kernels](../techniques/persistent-kernels.md) — Alternative approach to reducing launch overhead
-- [clc](clc.md) — Dynamic scheduling within persistent kernels

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/nvidia/hardware/tcgen05-mma/pitfalls-tcgen05-ptx.md

@@ -1,58 +0,0 @@
----
-id: pitfall-tcgen05-ptx
-type: pitfall
-vendor: nvidia
-title: Pitfalls
-architectures:
-- sm90
-- sm90a
-- sm100
-languages:
-- ptx
-- cuda-cpp
-hardware_features:
-- wgmma
-- cluster
-- tcgen05
-techniques:
-- shared-memory-optimization
-kernel_types:
-- gemm
-confidence: inferred
-evidence_level: inferred
-tags:
-- wgmma
-- cluster
-- tcgen05
-- shared-memory-optimization
-- gemm
-- ptx
-- cuda-cpp
----
-# tcgen05 Pitfalls
-
-**Note**: All pitfalls listed here are derived from spec analysis and cutlass source inspection. None have been verified on hardware (H200 is sm_90a; Blackwell requires sm_100+).
-
-## 1. Not available on H200 (sm_90a)
-
-**Problem**: Attempting to use `tcgen05.*` PTX instructions on an H200 will fail at compile time (`ptxas` rejects the instruction for `sm_90a`) or at runtime if the PTX is somehow loaded.
-
-**Trigger**: Using `-arch=sm_90a` or `-gencode=arch=compute_90a,code=sm_90a` with code that contains tcgen05 inline PTX.
-
-**Mitigation**: Guard tcgen05 code with `#if __CUDA_ARCH__ >= 1000` or use `-arch=sm_100a`. This KB entry exists for forward planning only.
-
-## 2. Opaque tcgen05 register file
-
-**Problem**: Unlike wgmma (which uses smem descriptors) or mma.sync (which uses standard registers), tcgen05 introduces a separate "tcgen05 register file" that is not directly addressable from C/C++. Data must be loaded via `tcgen05.cp` and read back via `tcgen05.ld`. Attempting to pass standard register values directly to the tcgen05 MMA instruction will fail.
-
-**Trigger**: Trying to use the same inline-PTX patterns from wgmma-ptx with tcgen05 without switching to the tcgen05.cp/ld flow.
-
-**Mitigation**: Follow the cutlass SM100 copy atom pattern: `tcgen05.cp` to load from smem, then issue the MMA referencing the tcgen05 register address, then `tcgen05.ld` to read results back into standard registers.
-
-## 3. CTA group sizing
-
-**Problem**: `tcgen05.cp.cta_group::1` and `tcgen05.cp.cta_group::2` encode different cooperative-group sizes. Using the wrong CTA group size for the kernel's thread configuration will cause incorrect data distribution or hangs.
-
-**Trigger**: Mismatching the `cta_group` parameter with the kernel's actual cluster/CTA configuration.
-
-**Mitigation**: Match the `cta_group` parameter to the number of CTAs participating in the cooperative copy. Consult the cutlass SM100 collective mainloop for reference configurations.