Issues / #1758
#1758 [Feature]: fail the test build when a release-engine CUDA kernel spills registers or uses local memory (per sm_)
open · @Avicennasis · 0 comments · View on GitHub
Description
### What do you want to do? A build-time check that fails `STRATA_BUILD_TESTS` when a CUDA kernel in the release engine spills registers to local memory or uses local memory at all, per architecture in `CMAKE_CUDA_ARCHITECTURES`. **Why.** Strata now carries per-architecture kernel tables and recently found two defects that were compiler-output facts rather than source facts: #1522 (`gdn_l2_kernel` compiles without the fma the fused kernel spells out on CUDA 13.3 / sm_120) and #1469 (Pascal decode regression). A register spill is the same kind of fact: it shows up in `ptxas -v` output and nowhere in the source, it varies by toolkit and `sm_`, and it costs decode throughput silently. Today nothing in the tree reads that output (`git grep -i 'ptxas\|spill\|resource-usage'` on `fb58e0d` finds only the SYCL docs and the conversation-cache "spilled" event). **Shape.** Build the kernel translation units with `-Xptxas -v` (or `--resource-usage`) in the test configuration, capture the per-kernel lines, and fail when `spill stores`/`spill loads` is non-zero or `lmem` is non-zero for a kernel on an allow-list of the hot decode/prefill kernels (`tests/cuda/` already names the prefill fused IQ/MoE/MMQ kernels). A kernel that legitimately needs local memory gets an entry in a short exceptions table with the number it is allowed, so a change that adds a spill is a red test with the kernel's name, the `sm_`, and the two numbers in the message. This is how DeepGEMM gates its kernels (`DG_JIT_CHECK_NO_SPILLS` / `DG_JIT_CHECK_NO_LOCAL_MEMORY`, asserted in its sanitizer run), and it needs no GPU at test time: the numbers come from the compiler, so it runs wherever the engine is built. **What I have not measured.** I have not run `ptxas -v` over Strata's kernels, so I am not reporting that any kernel spills today; this asks for the gate, not a fix. If you want it, I can send a PR that adds the capture and the allow-list with the numbers from an sm_86 and an sm_120 build, so the first run documents the current state rather than failing on it. Where in the tree the capture should live (a CMake option next to `STRATA_BUILD_TESTS`, or a `tools/` script over the build log) is your call.
Related on strata.com
Editorial links to help you install, pick models, or read release notes — not part of the upstream thread.