Skip to content
Tensormorph
Profiling
GPU kernels

GPU Kernels

🚧
This page is scoped conservatively: it covers what's confirmed about Tensormorph's compute-backend model, applied to kernel-level profiling. There is no local NVIDIA Nsight Compute reference in this workspace, and detailed kernel-metrics UI (a roofline chart, an occupancy calculator, and similar) is not a confirmed part of Tensormorph's design - treat any such feature as a plausible future direction, not documented fact.

Kernel-level profiling asks a narrower question than runtime tracing: not "what did this tensor's values look like," but "how efficiently did the compute that produced it actually run" - which specific kernel launch, on which backend, took how long.

What's confirmed

Tensormorph's GPU Backend Compatibility model already establishes the pieces a kernel-level view would build on: operations are placed across five backends (CPU, WebGPU, CUDA, ROCm, Metal) by capability and cost, and the Compute panel shows which backend actually served a given operation. A kernel-level profiling view, if you're looking for one, is the natural place to see how well that placement performed, not just which backend was chosen.

Importing an external trace

Given the confirmed emphasis on interoperability elsewhere in Tensormorph (reading safetensors, ONNX, and Hub-hosted checkpoints without requiring a proprietary format first), the most likely path for deep kernel-level analysis is importing a trace already captured by a dedicated profiling tool for your target backend, rather than Tensormorph reimplementing a full kernel-level profiler for every backend it supports. Treat that as a reasonable expectation, not a documented feature.

What to use instead, today

For CUDA workloads specifically, NVIDIA's own Nsight Compute (kernel-level) and Nsight Systems (timeline-level) tools remain the authoritative source for this kind of analysis until Tensormorph's own story here is finalized.

Related resources

FLOPsPerformance baselines