---
name: lightop-kernel-knowledge
description: "Use when adding or optimizing LightOp fused operators for DCU/ROCm and upstream evidence is needed: inspect local LightOp source/tests/configs, search ROCm/HIP/MIOpen/rocBLAS/hipBLASLt/Composable Kernel/Triton AMD/PyTorch ROCm/SGLang or vLLM AMD implementations, consult official DCU/DTK/ROCm docs, and use the bundled CUDA PR corpus only as cross-platform inspiration."
allowed-tools: "Bash Read Grep Glob"
---

# LightOp Kernel Knowledge

This skill turns LightOp/DCU operator questions into citable implementation
evidence. Prefer local LightOp evidence first, then ROCm/DCU upstream evidence,
then cross-platform CUDA evidence only as inspiration.

Use it to answer questions like:

- How does LightOp expose and test a similar operator?
- Which `lightop/csrc/<family>` should this new operator live in?
- Which config table or dispatcher branch selects the current kernel?
- Has ROCm/PyTorch/Triton AMD/SGLang/vLLM shipped a similar DCU path?
- Which DCU profiler signal should drive the next edit?
- Is a CUDA PR idea portable to HIP/DCU, and what needs translation?

## Evidence Routes

Use one route or combine several. Record the route used in the research digest
or attempt ledger before letting the evidence shape code.

### Route A: Local LightOp Source

This is the primary route. Locate the LightOp checkout containing:

```text
setup.py
lightop/__init__.py
lightop/csrc/export.cpp
test/
```

Search these first:

```bash
rg -n "<op_name>|<binding_name>|<kernel_name>" lightop test setup.py setup_torch29.py
rg -n "m\.def\(\"<op_name>|<wrapper_name>" lightop/csrc/export.cpp lightop/*.py
rg -n "get_.*config|gfx|gcnArchName|PYTORCH_ROCM_ARCH" lightop/config*.py setup.py setup_torch29.py
```

Evidence to record:

- Python wrapper path and public API import path.
- `export.cpp` binding line.
- Kernel implementation files under `lightop/csrc/`.
- Config/dispatcher branch.
- Test and benchmark files.
- Baseline command and result.

### Route B: ROCm/DCU Upstream And Official Docs

Use this route for DCU-specific implementation or profiling questions. Prefer
official docs and upstream source over blogs or snippets.

Useful source families:

- Bundled MR evidence from the SourceFind LightOp repository:
  `sources/prs/sourcefind-lightop/` with artifacts under
  `evidence/pull-bundles/sourcefind-lightop/`.
- Bundled MR evidence from the DCU Toolkit flash-attention-cutlass repository:
  `sources/prs/flash-attention-cutlass/` with artifacts under
  `evidence/pull-bundles/flash-attention-cutlass/`.
- SourceFind DCU/DTK docs, especially the performance analysis tool guide:
  `https://developer.sourcefind.cn/gitbook//dcu_developer/DeveloperGuide/dcu_programming/DCU_programming_chapter3_7.html`
- ROCm/HIP docs and profiler docs.
- PyTorch ROCm implementation and tests.
- MIOpen, rocBLAS, hipBLASLt, Composable Kernel, AITer.
- Triton AMD backend.
- SGLang/vLLM AMD paths and tests.

Evidence to record:

- URL or local source path.
- Commit SHA or version when available.
- Exact file/function/config that informed the LightOp change.
- License/notice details if code is copied or adapted.

### Route C: Bundled PR Corpus

The bundled corpus still contains useful kernel engineering examples, but most
of it is CUDA/NVIDIA-oriented. Use it only when Route A and Route B are thin or
when a cross-platform algorithmic idea is needed.

Run from the knowledge root:

```bash
python3 scripts/query.py "<operator> <dtype> <symptom>" --compact --limit 30
python3 scripts/query.py "lightop dcu <operator>" --repo sourcefind-lightop --compact --limit 20
python3 scripts/query.py "flash attention dcu" --repo flash-attention-cutlass --compact --limit 20
python3 scripts/search-pr-diffs.py <term1> <term2> [--any] [--limit 100]
python3 scripts/get_page.py <pr-page-id>
```

Before borrowing an idea, open the bundle named by `artifact_dir`:

```text
evidence/pull-bundles/<repo>/gh-<id>/review.diff
evidence/pull-bundles/<repo>/gh-<id>/source-snapshot/
evidence/pull-bundles/<repo>/gh-<id>/upstream.json
evidence/pull-bundles/<repo>/gh-<id>/ORIGIN.yaml
evidence/pull-bundles/<repo>/mr-<id>/review.diff
evidence/pull-bundles/<repo>/mr-<id>/source-snapshot/
evidence/pull-bundles/<repo>/mr-<id>/upstream.json
evidence/pull-bundles/<repo>/mr-<id>/ORIGIN.yaml
```

Translation rules:

- Treat CUTLASS/CuTe/PTX/SASS/TMA/WGMMA/tcgen05/Nsight evidence as
  non-portable until translated.
- Map CUDA concepts to ROCm concepts explicitly: SM to CU, warp to wavefront
  where appropriate, shared memory to LDS, tensor-core paths to MFMA or the
  selected ROCm library/backend.
- Do not cite CUDA profiler metrics as evidence for a DCU bottleneck.
- Record the CUDA source as inspiration, not as a DCU implementation proof.

### Route D: External Source Map

`index.json` may list complementary source repositories. Clone first, then
grep locally:

```bash
python3 scripts/clone-index-repos.py
python3 scripts/search-index-repos.py <term1> <term2> [<term3>]
```

Use this route only when the repository map is relevant to the current LightOp
operator. Prefer adding ROCm/DCU repositories to the source map before relying
on NVIDIA-only examples for DCU work.

## Query Patterns

For LightOp source:

```text
rmsnorm export.cpp wrapper test config
moe w8a8 gfx936 config benchmark
fuse silu quant op binding csrc
sourcefind-lightop gfx938 fused op test
flash-attention-cutlass dcu attention benchmark
```

For DCU profiling:

```text
hipprof launch overhead LightOp <op>
rocprof-compute LDS bank conflict HIP kernel
ROCm VGPR occupancy HIP kernel
MFMA utilization Composable Kernel grouped gemm
```

For cross-platform inspiration:

```text
rmsnorm vectorized load reduction PR
moe grouped gemm quantization dispatch PR
topk softmax fusion benchmark PR
```

## Citation Checklist

Apply the same citation shape to every finding:

- Route name.
- Source path or URL.
- Commit/version when available.
- Function, binding, config key, test, or benchmark that matters.
- What the evidence changes in the LightOp plan.
- Whether the idea is directly portable to DCU or only cross-platform
  inspiration.
- License/notice details if code is copied or adapted.

If a route returns a thin or empty match, widen search terms or cross-check
another route before treating it as a finding.

## Validate

The bundled corpus can still be validated with:

```bash
python3 scripts/validate.py
```

Validation of LightOp evidence means running the targeted LightOp build, test,
benchmark, and profiler commands named by `lightop-kernel-agent-loop`.
