Probe: sub-pel interpolation = a BF16 16×16 tile op (HEVC 8-tap, measured on real AMX)

[AdaWorldAPI]

What

The next measurement from the HEVC amortization map (#234): HEVC fractional-pel motion compensation applies a separable 8-tap FIR (half-pel luma taps [-1, 4, -11, 40, 40, -11, 4, -1] / 64). An FIR is a linear operator, so filtering a 16×16 block is a matrix product — one bf16_tile_gemm_16x16 per pass. The full separable H+V is Hᵀ·(X·H): the same two-tile "sandwich" shape as the splat covariance projection (Mᵀ·Σ·M, #233) and the codec transform (M·X, #232).

Measured — real AMX

This host: AMX TDPBF16PS, amx_available = true. Checked against a direct 8-tap FIR f64 reference using the same 16×16 band operator (reflected edges), so only BF16 rounding differs:

pass	op count	Frobenius rel err
horizontal 8-tap X·H	1 tile op	0.157%
separable H+V Hᵀ·(X·H)	2 tile ops	0.215%
throughput	—	1.22 M tile-ops/s

Both hard asserts pass (rel err < BF16 tolerance).

Why it matters

Fractional-pel motion is "just another tile op" — closing the MC story past integer-pel (M1 handled integer-pel gather; this handles the sub-pel filter). Combined with #230–#233, five HEVC DSP stages now measured onto the one BF16 tile primitive.

Honesty / R-5: this shows the equivalence (FIR == tile GEMM), not that the tile path is the right dispatch for a single block. Per the R-5 rule, a per-block 8-tap butterfly wins below the per-arch batch crossover (SPR 64, ICX 32, …); the batched tile GEMM wins above it. Ship both, dispatch on N.

x86-gated via the same #[cfg(target_arch = "x86_64")] mod amx + non-x86 fallback-main pattern as #233; canonical ndarray::simd::* imports; cargo fmt --check + cargo clippy clean, feature-gated required-features = ["std"].

Run: cargo run --release --example subpel_tap_tile --features std

🤖 Generated with Claude Code

---

Generated by Claude Code

[coderabbitai]

Warning

Review limit reached

@AdaWorldAPI, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 25 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 38d6bf78-5828-484e-8ba6-c6774419995b

📥 Commits

Reviewing files that changed from the base of the PR and between bbca88e and d6c9e1c.

📒 Files selected for processing (2)

• Cargo.toml
• examples/subpel_tap_tile.rs

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}