Probe: gridlake field interdependency = one BF16 16×16 AMX tile op (measured on real AMX) by AdaWorldAPI · Pull Request #233 · AdaWorldAPI/ndarray

AdaWorldAPI · 2026-07-04T10:07:04Z

The claim

A gridlake's cell interdependency, treated as a field operation, reduces to a BF16 16×16 AMX tile GEMM (TDPBF16PS) — the same shape as the intercorrelation / perturbation in a Gaussian splat (the EWA covariance sandwich Σ' = Mᵀ·Σ·M, shipped as hpc::splat3d::spd3::sandwich_x16).

Mechanically: a field operation whose output cell is a linear combination of input cells is a linear operator C = A·B — a GEMM, and the "interdependency" is the coupling matrix. At the gridlake tile granularity (16×16 — a quadrant of the 64×64 gridlake) that GEMM is exactly one hpc::bf16_tile_gemm::bf16_tile_gemm_16x16 call = one TDPBF16PS tile op. It's the same primitive as:

the codec separable transform (Probe: motion = bit shift × transform no-op × shaping — the factorization, measured #232: M·X, WHT/DCT on a tile), and
the splat EWA covariance projection (sandwich_x16, Mᵀ·Σ·M).

Measured — on real AMX

This host selected the top tier: AMX TDPBF16PS, amx_available = true. Checked against a direct f64 reference; precision as Frobenius-relative ‖tile−direct‖_F / ‖direct‖_F (the honest aggregate — a per-element max-relative blows up on the near-zero entries a cancellation-heavy Mᵀ·Σ·M naturally has, which measures the cancellation, not the kernel).

what	op count	Frobenius rel err
(1) intercorrelation `C = Xᵀ·X`	1 tile op	0.095%
(2) covariance sandwich `Σ' = Mᵀ·Σ·M` (splat EWA shape)	2 tile ops	0.401%
(3) bit-exact on bf16-exact integer operands (\|Σ\|<2²⁴)	—	true
(4) throughput	—	1.22 M tile-ops/s

Both hard asserts pass (Frobenius rel err < 5%, integer path bit-exact).

Conclusion

Yes — the gridlake field interdependency reduces to one BF16 16×16 tile op, matching the direct reference to BF16 precision and bit-exact for bf16-exact integer operands. Interdependency / intercorrelation / perturbation / codec transform / covariance projection are one op: the 16×16 BF16 tile GEMM. The 64×64 gridlake is 4×4 = 16 of these tiles.

This closes the arc across the recent probes — the codec transform (#232 M·X), the field coupling (this, Xᵀ·X / Mᵀ·Σ·M), and the splat covariance sandwich (sandwich_x16) are all the same AMX tile primitive. A note it surfaced honestly: chaining tile ops through bf16 intermediates needs scale/normalisation (real covariances are normalised for exactly this reason) — but with sane operand scale the two-op sandwich stays at 0.4%.

cargo fmt --check + cargo clippy clean, feature-gated required-features = ["std"].

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

🤖 Generated with Claude Code

Generated by Claude Code

coderabbitai · 2026-07-04T10:07:14Z

Warning

Review limit reached

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

Next review available in: 31 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: 27021843-ae0a-4d6e-84c8-36623d5c84ff

📥 Commits

Reviewing files that changed from the base of the PR and between 1ea77e8 and f10c2c4.

📒 Files selected for processing (3)

.gitattributes
Cargo.toml
examples/gridlake_field_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

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

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 89bbcf82e0

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-07-04T10:10:22Z

+use ndarray::hpc::amx_matmul::amx_available;
+use ndarray::hpc::bf16_tile_gemm::{bf16_tile_gemm_16x16, bf16_tile_gemm_tier};


Gate the example's AMX imports to x86_64

This example is registered with only required-features = ["std"], but hpc::amx_matmul and hpc::bf16_tile_gemm are compiled only under #[cfg(target_arch = "x86_64")] in src/hpc/mod.rs. On non-x86 targets, any cargo check --examples --features std or cross-target example build that includes this new target will fail with unresolved imports, so either add a non-x86 stub/cfg in the example or avoid the x86-only wrapper there.

Useful? React with 👍 / 👎.

…ce (#233, codex P2) The example imported the x86_64-only hpc::amx_matmul / hpc::bf16_tile_gemm paths under required-features = ["std"], so a cross-target `cargo check --examples` would fail on non-x86 with unresolved imports. Fixes: - Wrap the whole probe in `#[cfg(target_arch = "x86_64")] mod amx { ... }` with a `#[cfg(not(target_arch = "x86_64"))]` fallback `main` that prints the x86-only requirement. Non-x86 builds now compile (and skip) cleanly. - Switch to the canonical `ndarray::simd::*` surface (per the W1a consumer contract — consumers import from `ndarray::simd`, not raw `hpc::*`): `amx_available`, `bf16_tile_gemm_16x16_amx` (the TDPBF16PS tile wrapper, aliased to the body's name), `bf16_tile_gemm_tier` — all arch-gated re-exports. Behaviour unchanged on x86: still runs the real AMX TDPBF16PS tile op (amx_available = true), 0.095% / 0.401% Frobenius, bit-exact on integer operands. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MLBnPuScZy6w9di2QEjsXM

…VC 8-tap) Next probe from the HEVC amortization map: 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, and 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 on real AMX (this host: AMX TDPBF16PS, amx_available = true), vs a direct 8-tap FIR f64 reference (same 16×16 band operator, reflected edges, so only BF16 rounding differs): (1) horizontal 8-tap out = X·H frobenius_rel_err = 0.157% (one tile op) (2) separable H+V out = Hᵀ·(X·H) frobenius_rel_err = 0.215% (two tile ops) (3) throughput: 1.22 M sub-pel tile ops/s Both asserts pass (rel err < BF16 tolerance). Fractional-pel motion is therefore "just another tile op", closing the MC story past integer-pel. R-5 dispatch noted (per-block 8-tap butterfly below the batch crossover, batched tile GEMM above). x86-gated via the same `mod amx` / non-x86 fallback-main pattern as gridlake_field_tile; canonical ndarray::simd imports; fmt + clippy clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MLBnPuScZy6w9di2QEjsXM

…ce (#233, codex P2) The example imported the x86_64-only hpc::amx_matmul / hpc::bf16_tile_gemm paths under required-features = ["std"], so a cross-target `cargo check --examples` would fail on non-x86 with unresolved imports. Fixes: - Wrap the whole probe in `#[cfg(target_arch = "x86_64")] mod amx { ... }` with a `#[cfg(not(target_arch = "x86_64"))]` fallback `main` that prints the x86-only requirement. Non-x86 builds now compile (and skip) cleanly. - Switch to the canonical `ndarray::simd::*` surface (per the W1a consumer contract — consumers import from `ndarray::simd`, not raw `hpc::*`): `amx_available`, `bf16_tile_gemm_16x16_amx` (the TDPBF16PS tile wrapper, aliased to the body's name), `bf16_tile_gemm_tier` — all arch-gated re-exports. Behaviour unchanged on x86: still runs the real AMX TDPBF16PS tile op (amx_available = true), 0.095% / 0.401% Frobenius, bit-exact on integer operands. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MLBnPuScZy6w9di2QEjsXM

…ubstrate The durable ledger for the operator's thesis: use the BF16 16×16 AMX GEMM / blasgraph neighborhood / Morton-tile pyramid / perturbation-shader cascade to amortize H.265/HEVC — the per-block cost collapsing to a gather (bit shift) + one TDPBF16PS tile op over a deterministic pyramid built once. Maps every HEVC DSP stage to the substrate primitive, each row tagged MEASURED (#PR) / MECHANISM-unmeasured (probe named) / DOESN'T-FIT: - Motion estimation/compensation → i8/bf16 GEMM + gather [MEASURED #230] - Inverse transform → separable tile GEMM; WHT no-op [MEASURED #232] - Intra prediction / covariance → field-coupling tile op [MEASURED shape #233] - Sub-pel interpolation (8-tap) → separable tile GEMM [MECHANISM — probe] - CTU quad-tree → Morton/HHTL cascade [MECHANISM — shipped] - Deblock/SAO → masked tile op + LUT (the "AMX masking") [PARTIAL — masking] - CABAC entropy → serial arithmetic coding [DOESN'T FIT] Two honest boundaries recorded: (1) CABAC is not a GEMM — the entropy layer is the M2 serial front-end the tile substrate does not amortize; (2) the golden-spiral codec is for directional/sparse data, not dense scalar residuals (#231, measured negative). Cross-repo tie grounded: OGAR's perturbation pyramid IS the Walsh-Hadamard transform of the address tree = the same WHT #232 measured as the codec transform. Includes a probe queue (subpel_tap_tile, intra_angular_tile, deblock_masked_tile, CTU routing parity, M2 CABAC). Anchors: PRs #230–#233; hpc::bf16_tile_gemm, splat3d::spd3, cascade, codec; blasgraph HHTL; OGAR perturbation pyramid. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MLBnPuScZy6w9di2QEjsXM

… — measured The operator's claim: a gridlake's cell interdependency, treated as a field operation, reduces to a BF16 16×16 AMX tile GEMM (TDPBF16PS) — the same shape as the intercorrelation / perturbation in a Gaussian splat (the EWA covariance sandwich Σ' = Mᵀ·Σ·M, shipped as hpc::splat3d::spd3::sandwich_x16). Mechanically: a field operation whose output cell is a linear combination of input cells is a linear operator C = A·B — a GEMM; the interdependency IS the coupling matrix. At the gridlake tile granularity (16×16 — a quadrant of the 64×64 gridlake) that GEMM is exactly one hpc::bf16_tile_gemm::bf16_tile_gemm_16x16 call = one TDPBF16PS tile op. Same primitive as the codec separable transform (#232: M·X, WHT/DCT on a tile) and the splat covariance projection (sandwich_x16). Measured on the shipped kernel (this host: AMX TDPBF16PS, amx_available = true), vs a direct f64 reference. Precision reported as Frobenius-relative ‖tile−direct‖_F/‖direct‖_F (the honest aggregate — a per-element max-relative blows up on the near-zero entries a cancellation-heavy Mᵀ·Σ·M naturally has): (1) intercorrelation C = Xᵀ·X frobenius_rel_err = 0.095% (one tile op) (2) covariance sandwich Σ' = Mᵀ·Σ·M frobenius_rel_err = 0.401% (two tile ops) (3) bit-exact on bf16-exact integer operands (|Σ| < 2^24): true (4) throughput: 1.22 M tile-ops/s Conclusion: YES — the gridlake field interdependency reduces to one BF16 16×16 tile op, matching the direct reference to BF16 precision and bit-exact for bf16-exact integer operands. Interdependency / intercorrelation / perturbation / codec transform / covariance projection are ONE op: the 16×16 BF16 tile GEMM. The 64×64 gridlake is 4×4 = 16 of these tiles. fmt + clippy clean, gated required-features = ["std"]. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MLBnPuScZy6w9di2QEjsXM

…ce (#233, codex P2) The example imported the x86_64-only hpc::amx_matmul / hpc::bf16_tile_gemm paths under required-features = ["std"], so a cross-target `cargo check --examples` would fail on non-x86 with unresolved imports. Fixes: - Wrap the whole probe in `#[cfg(target_arch = "x86_64")] mod amx { ... }` with a `#[cfg(not(target_arch = "x86_64"))]` fallback `main` that prints the x86-only requirement. Non-x86 builds now compile (and skip) cleanly. - Switch to the canonical `ndarray::simd::*` surface (per the W1a consumer contract — consumers import from `ndarray::simd`, not raw `hpc::*`): `amx_available`, `bf16_tile_gemm_16x16_amx` (the TDPBF16PS tile wrapper, aliased to the body's name), `bf16_tile_gemm_tier` — all arch-gated re-exports. Behaviour unchanged on x86: still runs the real AMX TDPBF16PS tile op (amx_available = true), 0.095% / 0.401% Frobenius, bit-exact on integer operands. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MLBnPuScZy6w9di2QEjsXM

Every topic branch that adds a [[example]] entry collides on the same region of Cargo.toml, so each merge dirties the next chained PR. The built-in `union` merge driver keeps both sides of an additive conflict hunk — exactly right for this append-only list — and GitHub's merge honors it. Once this lands on master, subsequent example-adding PRs merge with no manual conflict resolution. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MLBnPuScZy6w9di2QEjsXM

…VC 8-tap) Next probe from the HEVC amortization map: 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, and 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 on real AMX (this host: AMX TDPBF16PS, amx_available = true), vs a direct 8-tap FIR f64 reference (same 16×16 band operator, reflected edges, so only BF16 rounding differs): (1) horizontal 8-tap out = X·H frobenius_rel_err = 0.157% (one tile op) (2) separable H+V out = Hᵀ·(X·H) frobenius_rel_err = 0.215% (two tile ops) (3) throughput: 1.22 M sub-pel tile ops/s Both asserts pass (rel err < BF16 tolerance). Fractional-pel motion is therefore "just another tile op", closing the MC story past integer-pel. R-5 dispatch noted (per-block 8-tap butterfly below the batch crossover, batched tile GEMM above). x86-gated via the same `mod amx` / non-x86 fallback-main pattern as gridlake_field_tile; canonical ndarray::simd imports; fmt + clippy clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MLBnPuScZy6w9di2QEjsXM

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MLBnPuScZy6w9di2QEjsXM

…ubstrate The durable ledger for the operator's thesis: use the BF16 16×16 AMX GEMM / blasgraph neighborhood / Morton-tile pyramid / perturbation-shader cascade to amortize H.265/HEVC — the per-block cost collapsing to a gather (bit shift) + one TDPBF16PS tile op over a deterministic pyramid built once. Maps every HEVC DSP stage to the substrate primitive, each row tagged MEASURED (#PR) / MECHANISM-unmeasured (probe named) / DOESN'T-FIT: - Motion estimation/compensation → i8/bf16 GEMM + gather [MEASURED #230] - Inverse transform → separable tile GEMM; WHT no-op [MEASURED #232] - Intra prediction / covariance → field-coupling tile op [MEASURED shape #233] - Sub-pel interpolation (8-tap) → separable tile GEMM [MECHANISM — probe] - CTU quad-tree → Morton/HHTL cascade [MECHANISM — shipped] - Deblock/SAO → masked tile op + LUT (the "AMX masking") [PARTIAL — masking] - CABAC entropy → serial arithmetic coding [DOESN'T FIT] Two honest boundaries recorded: (1) CABAC is not a GEMM — the entropy layer is the M2 serial front-end the tile substrate does not amortize; (2) the golden-spiral codec is for directional/sparse data, not dense scalar residuals (#231, measured negative). Cross-repo tie grounded: OGAR's perturbation pyramid IS the Walsh-Hadamard transform of the address tree = the same WHT #232 measured as the codec transform. Includes a probe queue (subpel_tap_tile, intra_angular_tile, deblock_masked_tile, CTU routing parity, M2 CABAC). Anchors: PRs #230–#233; hpc::bf16_tile_gemm, splat3d::spd3, cascade, codec; blasgraph HHTL; OGAR perturbation pyramid. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MLBnPuScZy6w9di2QEjsXM

…VC 8-tap) Next probe from the HEVC amortization map: 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, and 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 on real AMX (this host: AMX TDPBF16PS, amx_available = true), vs a direct 8-tap FIR f64 reference (same 16×16 band operator, reflected edges, so only BF16 rounding differs): (1) horizontal 8-tap out = X·H frobenius_rel_err = 0.157% (one tile op) (2) separable H+V out = Hᵀ·(X·H) frobenius_rel_err = 0.215% (two tile ops) (3) throughput: 1.22 M sub-pel tile ops/s Both asserts pass (rel err < BF16 tolerance). Fractional-pel motion is therefore "just another tile op", closing the MC story past integer-pel. R-5 dispatch noted (per-block 8-tap butterfly below the batch crossover, batched tile GEMM above). x86-gated via the same `mod amx` / non-x86 fallback-main pattern as gridlake_field_tile; canonical ndarray::simd imports; fmt + clippy clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MLBnPuScZy6w9di2QEjsXM

chatgpt-codex-connector Bot reviewed Jul 4, 2026

View reviewed changes

AdaWorldAPI mentioned this pull request Jul 4, 2026

Knowledge: HEVC/H.265 amortization map onto the BF16 16×16 AMX tile substrate #234

Merged

AdaWorldAPI mentioned this pull request Jul 4, 2026

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

Merged

AdaWorldAPI force-pushed the claude/gridlake-field-tile branch from 368e01d to 384761e Compare July 4, 2026 10:52

AdaWorldAPI force-pushed the claude/gridlake-field-tile branch from 384761e to a3193d2 Compare July 4, 2026 10:55

claude added 3 commits July 4, 2026 10:58

AdaWorldAPI force-pushed the claude/gridlake-field-tile branch from a3193d2 to f10c2c4 Compare July 4, 2026 10:58

AdaWorldAPI pushed a commit that referenced this pull request Jul 4, 2026

git: union-merge Cargo.toml (see #233) to end the example-list cascade

a075a58

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MLBnPuScZy6w9di2QEjsXM

AdaWorldAPI merged commit 071d40a into master Jul 4, 2026
17 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Probe: gridlake field interdependency = one BF16 16×16 AMX tile op (measured on real AMX)#233

Probe: gridlake field interdependency = one BF16 16×16 AMX tile op (measured on real AMX)#233
AdaWorldAPI merged 3 commits into
masterfrom
claude/gridlake-field-tile

AdaWorldAPI commented Jul 4, 2026

Uh oh!

coderabbitai Bot commented Jul 4, 2026 •

edited

Loading

Review limit reached

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

chatgpt-codex-connector Bot Jul 4, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		use ndarray::hpc::amx_matmul::amx_available;
		use ndarray::hpc::bf16_tile_gemm::{bf16_tile_gemm_16x16, bf16_tile_gemm_tier};

Conversation

AdaWorldAPI commented Jul 4, 2026

The claim

Measured — on real AMX

Conclusion

Uh oh!

coderabbitai Bot commented Jul 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review limit reached

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Jul 4, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

coderabbitai Bot commented Jul 4, 2026 •

edited

Loading