fkl-data-structures
Handles GPU memory allocation and data structure wrapping for FKL pipelines.
Install
mkdir -p .claude/skills/fkl-data-structures && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/19361" && unzip -o skill.zip -d .claude/skills/fkl-data-structures && rm skill.zipInstalls to .claude/skills/fkl-data-structures
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
FKL data structures — Ptr2D, Tensor, TensorT, RawPtr, PtrDims, MemType, constructors and memory layouts (packed, planar CHW, transposed T3D). Use when allocating or wrapping GPU memory for FKL pipelines, when interfacing external pointers (torch/cupy buffers), or when a Tensor/TensorT constructor or pitch issue appears.Key capabilities
- →Allocate GPU memory for FKL pipelines
- →Wrap external pointers from torch or cupy
- →Manage memory layouts including packed and planar CHW
- →Define memory types for FKL data structures
- →Perform zero-copy interop with external frameworks
How it works
It provides a hierarchy of data structures like RawPtr and Tensor to manage GPU memory layouts. It allows wrapping external pointers without copying by specifying memory types and pitch parameters.
Inputs & outputs
When to use fkl-data-structures
- →Allocating GPU memory for image processing
- →Wrapping external buffers from torch or cupy
- →Handling pitched memory layouts for 3D tensors
- →Defining memory types for FKL pipelines
About this skill
FKL data structures
The hierarchy
RawPtr<ND, T>— POD: data pointer +PtrDims<ND>. What kernels see.Ptr<ND, T>— ref-counted owner/wrapper around a RawPtr.- Convenience classes:
Ptr1D,Ptr2D,Ptr3D,Tensor,TensorT. .ptr()returns the RawPtr;Op::build(container)extracts what it needs. Copies of Ptr objects are SHALLOW (shared refcount).
Dimensionalities (ND)
| ND | layout | use |
|---|---|---|
_1D | w | flat arrays |
_2D | w x h (pitched) | images |
_3D | w x h x planes x color_planes | batched images / planar CHW |
T3D | transposed: color_planes outermost | NCHW-like DNN ingest |
Constructors that matter (and their traps)
// allocating
Ptr2D<uchar3> img(width, height); // device by default
Tensor<float> t(width, height, planes, color_planes); // 3D batch
// wrapping EXTERNAL memory (zero-copy interop):
Ptr2D<float> wrap(devPtr, width, height, pitchBytes, MemType::Device);
Tensor<float> wrapT(devPtr, width, height, planes, color_planes, MemType::Device);
TRAPS (verified the hard way):
Tensorhas NO PtrDims-taking constructor — pass the dimension list.Tensor's semantics for batch+channels:planes= batch (thread.z),color_planes= channels.TensorSplitwrites channel c of plane z at offsetz * plane_pitch * color_planes + c * plane_pitch.TensorT(data, ...)and the 4-argPtrDims<T3D>constructor leave pitches at ZERO (they are filled on allocation). When wrapping an external pointer for T3D, build the PtrDims and set pitch, plane_pitch, color_planes_pitch manually, then construct theRawPtr<T3D>and pass it toTensorTSplit<T>::build(rawPtr).- Pitch is in BYTES. For tightly-packed external buffers, pitch = width * sizeof(T).
MemType
Device, Host, HostPinned, DeviceAndPinned (mirrored pair with .upload(stream) / .download(stream)). GPU pipelines require Device or DeviceAndPinned memory — CircularTensor enforces this at runtime.
Layout cheat-sheet for DNN interop
| want | use | output shape |
|---|---|---|
| packed HWC batch | TensorWrite<T> | (batch, H, W, C-packed-in-T) |
| planar CHW per image | TensorSplit<T> | (batch, C, H, W) |
| planar, C outermost | TensorTSplit<T> into TensorT | (C, batch, H, W) |
| read planar back as packed | TensorPack<T> / TensorTPack<T> | — |
Vector pixel types
Channels are encoded in the TYPE: uchar3, float4, etc.
VBase<T>= scalar base,cn<T>= channels,VectorType_t<base, n>.- Per-channel arithmetic operators are predefined (vector_utils.h).
- 16-bit types (
ushort3,short2) work like the 8/32-bit ones.
External-framework interop (what bindings do)
A torch/cupy CUDA tensor is wrapped without copying:
Ptr2D<float> in((float*)cuda_ptr, w, h, w * sizeof(float), MemType::Device);
Stream s(reinterpret_cast<cudaStream_t>(framework_stream)); // non-owning
Contiguity is the caller's responsibility (require C-contiguous or read strides into the pitch argument).
When not to use it
- →When using non-GPU memory for FKL pipelines
- →When attempting to use Tensor constructors without dimension lists
Prerequisites
Limitations
- →Pitch must be calculated in bytes
- →Tensor constructors require explicit dimension lists
How it compares
This approach provides explicit control over memory layout and pitch for GPU kernels compared to generic framework-level tensor abstractions.
Compared to similar skills
fkl-data-structures side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| fkl-data-structures (this skill) | 0 | 15d | No flags | Advanced |
| mlir-development | 1 | 6mo | Review | Advanced |
| compiler-development | 1 | 6mo | No flags | Advanced |
| add-cuda-kernel | 1 | 3mo | Review | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
mlir-development
gmh5225
Expertise in MLIR (Multi-Level Intermediate Representation) and CIR (Clang IR) development for domain-specific compilation and high-level optimizations. Use this skill when building ML compilers, domain-specific languages, or working with multi-level compilation pipelines.
compiler-development
gmh5225
Expertise in compiler development using LLVM infrastructure including frontend design, IR generation, optimization passes, and code generation. Use this skill when building custom programming languages, implementing DSL compilers, or working on compiler internals.
add-cuda-kernel
flashinfer-ai
Step-by-step tutorial for adding new CUDA kernels to FlashInfer
benchmark-kernel
flashinfer-ai
Guide for benchmarking FlashInfer kernels with CUPTI timing
debug-quantized-kernel-accuracy
tensormux
2. **Isolate the quantization step responsible.** The quantization pipeline is: ``` fp32 input → quantize → int8 input int8 GEMM (or other op) with int32 accumulation int32 accumulation → dequantize → fp32/fp16 output ``` Test each boundary: - **Quant-dequant roundtrip**: quantiz
procedural-generation
XeldarAlz
Procedural generation patterns — Perlin/Simplex noise, BSP dungeon generation, random walk, loot tables with weighted random, wave function collapse basics, seed-based reproducibility.