Matsuoka's Revised FP8 Papers Concede the 3-D FFT in Software and Name One Hardware Block That Could Also Lift Emulated DGEMM

In plain terms

Satoshi Matsuoka of RIKEN argues that FP8 tensor cores built for AI can perform much of the multiplication work in several scientific-computing kernels at double-precision accuracy: split each number into small integer pieces, multiply those pieces on the AI hardware, then rebuild the answer. The September revisions give ground. Of the five core operations the thesis set out to cover, the FFT no longer reaches its performance target in software. The papers say the FFT needs a hardware ladder to reach its modeled target.

One component, a proposed converter, is part of what Matsuoka calls a "minor hardware assist"; neither paper sizes that converter for area or power. In the companion paper's model, that same converter could roughly double emulated dense matrix throughput on NVIDIA's Rubin, provided it meets the paper's throughput requirements. For buyers writing specifications now, Part 2 argues that post-Rubin GPUs intended for spectral workloads should either retain a stated floor of native double-precision throughput or provide the full emulation hardware it specifies.

All of this is revised performance modeling; no kernel timing has been measured. The procurement argument is Matsuoka's position rather than a finding, and it comes from inside the FugakuNEXT co-design.

Satoshi Matsuoka's own audit of the thesis he floated in May now gives up one of the five kernels it set out to cover. In three revised papers posted to arXiv on September 8, 2026, the director of the RIKEN Center for Computational Science concedes the 3-D FFT in software and models a hardware fix that his companion paper says could roughly double emulated dense matrix throughput on NVIDIA's Rubin. All three are revised performance models. Ozaki 2.5's abstract states that "every result is a model projection pending measurement," and Part 2 carries a section header reading "Status of the results: a model, not a measurement."

The three are a fourth version of "FP8 is All You Need (Part 1)", a third version of Part 2, now retitled around the full-FP64 3-D FFT, and a new companion called "Ozaki 2.5", which its arXiv comment field describes as "essentially a part 3 paper." All three name Matsuoka as sole author. The evaluation is narrow: bit-exact unit tests and library-call traces, with no kernel timing from hardware.

Part 1 states the revised claim: "four of the five canonical primitives reach the memory roof in software, and the fifth is effectively reachable with minor, independently-motivated hardware plus one moderate addition." The memory roof is the shortest time a kernel could take if the only limit were how fast the GPU moves data through its memory. The fifth primitive is the FFT. "For this one primitive of five," the paper says, "the thesis is conceded in software."

When SCN covered the first two papers in June, Part 2 projected a 1024³ FFT at roughly 18 ms against a 12.9 ms memory roof, within reach of FP8 tensor cores alone. In July, a joint paper with Jack Dongarra and Torsten Hoefler filed the program as "a research hypothesis rather than an established result." September withdraws the 18 ms figure. The same transform now lands at a projected 63 to 87 ms on NVIDIA's B300, and for the coming Rubin part the paper advises against running this route at all.

The FFT loses to integer overhead, so the papers turn to hardware

Ozaki Scheme II, the method underneath all three papers, splits each FP64 operand into small integer residues, multiplies the residues on FP8 tensor cores, and rebuilds the double-precision answer through the Chinese Remainder Theorem. In the FP8 implementation, the integer work around the tensor-core multiply is what bit. Part 2 charges it as a per-output "integer epilogue": the fixed run of ordinary integer instructions that every output value needs after the tensor-core multiply to become a double-precision result. The paper counts it at roughly 203 to 281 integer instructions per output, running one scalar at a time on the GPU's ordinary integer pipe.

Dense matrix multiplication, DGEMM, when done in double precision, hides the charge because each output amortizes a long inner product; HPL, the benchmark behind the TOP500 list, is built on DGEMM. A 1024³ transform, run as staged matrix products, has a short inner dimension and about a billion output scalars per pass, each carrying the charge.

The floor is an integer-issue rate: the pipe must keep up with memory bandwidth or the epilogue takes longer than moving the data. On the B300, the model demands 25 to 35 instructions per byte against a pipe that supplies about 5.2. Table 1 has the resulting projections.

Table 1. Part 2's projections for a 1024³ FFT, in milliseconds

The B300 comparison carries a condition: the native figure is modeled on a vector pipe cut to about 1.4 TFLOPS, and emulation's projected win holds only at peak integer issue. On Rubin, the model is shorter because native FP64 there reaches its own memory roof and the emulated route takes far longer. "This is a clean negative result, and we state it as such," Part 2 says. "Nothing in this paper should be run on a part whose native FP64 reaches its own memory roof." The advice is scoped to this full-FP64 FFT route under the paper's assumptions; the companion paper still models emulated DGEMM as a Rubin-scale gain.

Part 2's revision ledger records how the headline got from 18 ms to 63 ms, and the first item is a correctness failure the author reports himself. It concerns the modulus set, the list of primes the scheme divides by to make its residues; their combined size fixes how many bits it can rebuild exactly. The prime moduli used in every draft through June had a combined capacity of 111.84 bits and missed the paper's own budget by 2.16 bits, which meant "a constant (DC) input field already reconstructs wrong by exactly M." Three primes, 509, 503 and 499, are replaced by 2039, 2029 and 2027. Three earlier headline figures are "withdrawn, with retraction notes at the relevant sections."

What would remove the wall, in the model, is a ladder of three hardware additions, each priced in projected milliseconds and none in silicon area.

• The first rung restores an integer tensor core at the rate the B200 already shipped, which B300 and Rubin cut, and adds a new "position-weighted" accumulation primitive built on six INT64 group accumulators. Together they take the projected B300 transform to 29.2 to 48.1 ms.
• The second rung is a load-path conversion datapath plus multiword-carry and wide-conversion ISA idioms. It lands at 16.0 to 23.5 ms, conditional on that accumulator.
• The third rung, modular reduction at the tensor-core output, reaches 12.9 to 15.0 ms.

"We make no area claims," the paper says. One qualification sits under the optimistic end: the tensor-core count assumes a three-plane FP8 layout that Ozaki 2.5 proves exact only inside a stated envelope, and the three 11-bit primes the September revision introduced fall outside it, with "no exact three-plane layout ... proven for them." Reaching the roof after the ladder rests on a layout the paper has not proved.

The load-path converter in the second rung is also the dense paper's preferred hardware proposal. Part 2's abstract calls it "the load-path deconstruction datapath the companion papers ask for as Option C." Ozaki 2.5's co-design section models roughly doubling Rubin's large-square DGEMM throughput without enlarging the output one group of thread blocks can cover while sharing on-chip memory: from about 235 TFLOPS on hybrid set E to about 473 on published set S, which becomes the faster route once conversion leaves the compute pipes. E itself tops out near 438. The result depends on the proposed converter meeting the paper's transform-throughput and plane-deposit requirements; conversion time does not disappear. Under the same model, it also removes the conversion bottleneck from sparse kernels such as SpMV. The paper leaves "width, ports, area and power to the vendor."

Matsuoka's own characterization goes further. "For FFT we would need minor hardware assist to the current GPU architecture, and that addition would fundamentally speed up Ozaki II for other kernels," he told SCN by email on September 11. "This is a fundamental discovery especially outlined in the Ozaki 2.5 paper." "Minor" is his word; neither paper carries an area or power model for the converter.

Emulated DGEMM on Rubin gets a floor, with two conditions attached

Ozaki 2.5 engineers the other end of the pipeline, the conversion of operands into residues, and discloses a ceiling on the dense case that June's papers did not have. Its arithmetic roof for emulated DGEMM on Rubin, on NVIDIA's 17.5 PFLOPS dense FP8 rate, is reachable only within a single thread-block cluster, an output of at most 256². A thread-block cluster is a group of GPU thread blocks scheduled together so they can share on-chip memory directly. In this model, an output larger than one cluster's reach must re-split its operands once per cluster because those on-chip planes cannot be shared across clusters, and the modeled rate settles at what the paper calls the deconstruction floor, "≈235 TFLOPS on Rubin for cluster-aligned large squares," described as "a derived ratio of three design integers ... not a fitted efficiency." Large squares are the regime HPL runs in.

Table 2. Ozaki 2.5's modeled Rubin floors for emulated DGEMM, in TFLOPS

Two conditions travel with the 235 figure. It belongs to a co-designed modulus set the paper calls E, which has thirteen moduli and its own, lower arithmetic roof. The published set S, the one that "carries the round-to-nearest Ozaki II theorem," floors lower, and ragged sizes dip to a disclosed worst case of 0.36.

Then accuracy. The shipping FP8 implementation quantizes by truncation toward zero, which discards the low bits that do not fit; round-to-nearest, the rule the published proof assumes, picks the closest representable value instead. Ozaki 2.5's Appendix A says the published error theorem was proved for round-to-nearest: truncation "does not automatically inherit the RN bound, and TZ-grade accuracy remains an explicit validation obligation rather than an established result." A throughput figure on set E would not by itself establish FP64-equivalent numerical behavior; the paper treats that as a separate test it still owes.

The 0.50 figure is stated at an integer issue rate of 75 tera-instructions per second, the NVIDIA memo's normalization. Part 2's September revision derives 41.7 T inst/s instead from the published B300 FP32 rate, and Part 1's reconciliation note carries the consequence: at 41.7 T inst/s "the Rubin large-square floor [is] ≈148 TFLOPS (0.31 of 473) rather than 0.50." Both are model assumptions awaiting calibration rather than device specifications, and Ozaki 2.5 says the 1.8× gap "is exactly what the Part-3 integer-pipe census measures." Either way, the floor sits several times above Rubin's native FP64; Table 2 gives the multiples.

NVIDIA's own figure sits on its HGX page, which as of September 11 lists 200 TFLOPS of FP64 DGEMM per Rubin GPU, footnoted as "peak performance using Tensor Core-based emulation algorithms" and marked preliminary. Ozaki 2.5 calls it "a preliminary, 'up to' specification whose algorithm, mode, and benchmark dimensions are not published," and treats its own 235 TFLOPS as consistent with it. The B300's 135 TFLOPS roof "sits at its own floor," so it "gains little"; the remedy is the copy-path converter above, listed among asks "none yet present in silicon." "Ozaki 2.5" is Matsuoka's label, not the Ozaki Scheme II authors'; the abstract says the terminology "will be coordinated with the Ozaki-II/FP8-Ozaki-II authors."

NVIDIA's review prompted the correction; SCN found no outside reproduction

NVIDIA provided the correction that reorganized the bundle. Part 1 states that "the arXiv public release of this paper (arXiv:2606.06510v3, July 3, 2026) predates the NVIDIA technical review and everything that followed from it." The review, as Matsuoka describes it, is a technical note by Harun Bayraktar, John Gunnels, and Peter Caday, dated July 10, 2026. It identified the operand-conversion cost the June model omitted, and Ozaki 2.5 cites it "with permission." The note is not public. Whether the conversion path the note counted is the one behind NVIDIA's published B200 figure is, in Matsuoka's provenance appendix, a question "the memo's authors have been asked to confirm."

The papers describe "a shared cost engine and a consistency suite of several hundred checks" that re-derive every printed number, and review rounds "dispositioned item-by-item in a released response letter." That letter is public, attached to Part 1 as an arXiv ancillary file, as is a reproduction artifact of scripts, traces, and parameter files. The letter does not name the reviewers. Searches of arXiv, the web, and Hacker News on September 11 turned up no third-party reproduction of the model or either floor.

Part 2 argues buyers should hold a native FP64 floor

The bundle's rule for buyers is Matsuoka's position, not a finding. Part 2's version: "The FP64 floor for future GPUs is set by FFT, not by HPL. Designers tempted to cut FP64 vector silicon further on post-Rubin generations should treat η ≥ 1.56·B_HBM as a hard floor—because the software escape route is no longer free." In the formula, η is native FP64 vector throughput, and B_HBM is memory bandwidth. The coefficient comes from the paper's own transform, problem size, and traffic model; a different FFT formulation or size would give a different one.

At the 22 TB/s the papers assume for Rubin, that floor is 34.3 TFLOPS of FP64 vector throughput. Rubin's 33 TFLOPS spec sits 4% under it, which Part 2 calls "essentially at parity" and, elsewhere, parity "by design or by coincidence." The B300, at 8 TB/s, needs 12.5 TFLOPS and has about 1.4. The other memory-bound kernels ask far less; Part 1 puts sparse matrix-vector multiply at parity around 4.4 TFLOPS on Rubin. If the model holds, the FFT sets the highest native double-precision requirement among the five kernels, and the papers argue that whether a vendor should carry that silicon for one kernel class is a design choice.

Two hardware inputs sit under the argument. The papers compute every Rubin floor at 22 TB/s, which NVIDIA's HGX page lists alongside 33 TFLOPS of FP64 and 250 INT8 TOPS. NVIDIA's separate Vera Rubin NVL72 page lists 19.2 TB/s per GPU with the same 33 TFLOPS. As of September 11, the two pages differ, and the papers, which label their Rubin inputs "preliminary announced specifications," do not say which will ship. At 19.2 TB/s, the formula gives a floor near 30 TFLOPS, which would put Rubin's 33 above parity rather than just below it. The B300 inputs, about 167 dense INT8 TOPS and 1.39 FP64 TFLOPS per GPU, match NVIDIA's GB300 NVL72 page once its 72-GPU rack figures are divided out and its sparsity footnote is applied.

The alternative the paper names is to keep buying native FP64. Part 1 calls AMD's positioning around the MI430X "a coherent strategy" and expects "a portfolio in which some hardware provides native FP64 while other hardware leans on the FP8 primitive." Part 2 addresses its rule to "the broader 2028–2030 procurement window," the buyers writing specifications now.

Part 3 owes the measurements, and Rikyu alone cannot supply them

All three papers state the work "was undertaken as part of the FugakuNEXT project," and Part 2 says a hardened set of floors would give "the FugakuNEXT, Doudna, and Blue Lion communities a clean rule for evaluating post-Rubin GPU designs." That puts the bundle in the co-design of Japan's next flagship supercomputer, which pairs Fujitsu CPUs with NVIDIA GPUs and targets application performance rather than ranking position.

Ozaki 2.5 says the measurement sweep is "being automated on RIKEN's Rikyu GB200 NVL4 system," a 1,600-GPU Blackwell testbed in Kobe that RIKEN named on June 19. The paper is precise about its limits: "the GB200 testbed calibrates the model; it does not by itself validate GB300's reduced integer-tensor balance or Rubin's concurrency, which require those parts." Part 1 says a Part 3 companion "is in preparation for rapid publication, with substantially expanded experiments and adversarial scrutiny." No date is given.

What Part 3 owes is spelled out across the three papers:

• a measured epilogue instruction count, since Part 2 says "that single number decides which end of the range applies";
• the integer-pipe census;
• an accuracy suite for the truncation rule and for set E, without which the dense floor is a throughput number with no error bound attached;
• GB300 and Rubin parts on the bench, because Rikyu can calibrate the model but cannot close it.

Disclosure: Supercomputing News publisher Matt Walters is named in the acknowledgments of Part 1 "for discussions that helped sharpen the framing of the thesis." This analysis draws on the public papers, NVIDIA's published specifications, and one on-record email from the author, consistent with our June 15 and July 7 coverage. All three papers disclose substantial drafting assistance from Anthropic's Claude models under the author's direction; Part 1 and Ozaki 2.5 add that OpenAI's GPT-5.6 provided critical review.