Skip to content

docs(research): record the CUDA Tile additive-reduction gap - #1391

Draft
lusoris wants to merge 1 commit into
masterfrom
docs/cuda-tile-vif-spike
Draft

docs(research): record the CUDA Tile additive-reduction gap#1391
lusoris wants to merge 1 commit into
masterfrom
docs/cuda-tile-vif-spike

Conversation

@lusoris

@lusoris lusoris commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

Summary

Timeboxed spike closing out the CUDA Tile adoption question, run against the
kernel family where Tile looked most plausible — float_vif_compute.

The result is sharper than "not worth it": the Tile API in CUDA 13.3 has no
additive reduction primitive at all.
reduce_max, reduce_min,
reduce_bitand, reduce_bitor and reduce_bitxor are builtins; reduce_add
does not exist. Every hot kernel in this fork — float_vif_compute, the
integer_adm accumulators, float_moment, the SpEED covariance pass — is built
from additive reductions.

Measured on an RTX 4090 (sm_89), same 32×32 tile, only the operator differs:

kernel reduction REG SHARED
tile_max_native reduce_max (builtin) 24 0 B
tile_sum_via_scan additive, two partial_sum scans 47 4096 B

~2× the registers plus a 4 KB shared-memory staging buffer, to produce one
scalar the current SIMT path gets from a register-only warp shuffle.

Two further findings, both build-system rather than capability:

  • A __global__ function cannot call __tile__ code (calling a __tile__ function ... from a __global__ function is not allowed). Tile kernels need
    the separate __tile_global__ entry point, so a Tile port is a second
    parallel entry point plus host-side dispatch, not an incremental kernel edit.
  • A plain -cubin build with --enable-tile emits no SASS for tile kernels
    — only .note.nv.tkinfo and GLOBAL:0. Codegen lands only under
    --tilefatbin, in a separate fatbin section: a second build artifact for
    core/src/meson.build and the CUDA loader to manage.

Recommendation unchanged (do not adopt), now resting on a mechanism rather than
a judgement call. Revisit if a future CUDA release adds reduce_add.

Reproducer / smoke-test command

# reduce_add is absent from the API:
grep -oE 'reduce_[a-z_]+' /opt/cuda/include/crt/cuda_tile.h | sort -u
# -> reduce_bitand reduce_bitor reduce_bitxor reduce_max reduce_min

# Build the two kernels from the digest and compare resource usage:
nvcc --enable-tile --tilefatbin -std=c++20 -arch=sm_89 tile_spike.cu -o tile_spike.tilefatbin
cuobjdump -res-usage tile_spike.tilefatbin

The digest carries the full tile_spike.cu source.

Deep-dive deliverables (ADR-0108)

  • Research digestdocs/research/2040-cuda-tile-additive-reduction-gap.md.
  • Decision matrix — no alternatives: this PR records a measurement, it does not decide anything. The adoption decision it informs is unchanged.
  • AGENTS.md invariant note — no rebase-sensitive invariants; no code changes.
  • Reproducer / smoke-test command — above.
  • Changelog fragmentchangelog.d/added/2040-cuda-tile-spike.md, CHANGELOG.md regenerated.
  • Rebase note — no rebase impact: docs-only, no upstream counterpart.

Docs (rule 10)

Docs-only PR; no user-discoverable surface changes.

State (rule 13)

no state delta: a research measurement, no bug opened or closed.

🤖 Generated with Claude Code

The CUDA Tile audit recommended not adopting Tile C++. This timeboxed spike
tests that against the kernel family where Tile looked most plausible --
float_vif_compute, whose inner loop is a windowed statistics pass.

The result is sharper than "not worth it". The Tile API in CUDA 13.3 provides
no additive reduction at all: reduce_max, reduce_min and the three bitwise
reductions are builtins, reduce_add is absent. Every hot kernel in this fork
is built from additive reductions.

Measured on an RTX 4090 (sm_89), same 32x32 tile, only the operator differs:

  tile_max_native  (reduce_max)      REG:24  SHARED:0
  tile_sum_via_scan (two partial_sums) REG:47  SHARED:4096

~2x the registers and a 4 KB shared-memory staging buffer to produce one
scalar that the current SIMT path gets from a register-only warp shuffle.

Two further findings, both build-system rather than capability: a __global__
function cannot call __tile__ code, so a Tile port is a second parallel entry
point (__tile_global__) rather than an incremental edit; and a plain -cubin
build with --enable-tile emits no SASS for tile kernels at all -- codegen
lands only under --tilefatbin, in a separate fatbin section.

Revisit if a future CUDA adds reduce_add.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant