Methodology & Disclosure

Methodology & Disclosure


Resonetic Lab is an independent technical publication focused on real code changes in major AI infrastructure projects.


Each article begins with publicly available evidence such as a pull request, commit, issue, source file, test, benchmark, review discussion, or official technical document.


The purpose is not to summarize every changed line. The purpose is to identify the engineering question behind the change:


- What behavior failed or underperformed?

- Which assumption or system boundary caused it?

- What does the patch actually change?

- What evidence supports the proposed fix?

- What remains unverified or outside the scope of the change?


Research Method


For each code-review article, I may examine:


- The pull request and its final merged commit

- Changed source files

- Relevant callers and consumers

- Tests and test infrastructure

- Public issue reports and reproductions

- Review discussions

- Official specifications or platform documentation

- Reported benchmarks and validation results


Source-code and test links are pinned to a specific commit whenever practical so that the evidence does not change after publication.


Important Distinctions


A pull request description is a claim about the change. It is not, by itself, proof that the implementation satisfies that claim.


A passing test supports the behavior exercised by that test. It does not prove correctness across every backend, configuration, model, device, or workload.


A reported benchmark describes the tested environment. It should not be treated as a universal performance result.


A code-review article is an independent technical analysis. It is not an official project statement, a security audit, or a substitute for the project’s documentation and release notes.


Observed behavior, technical inference, and unconfirmed claims are kept separate whenever the available evidence allows.


Use of AI


AI tools may assist with source discovery, document organization, comparison of code paths, drafting, editing, and identifying questions that require further verification.


AI output is not treated as a factual source.


The selection of evidence, contract analysis, interpretation of the change, review verdict, scope boundaries, and final publication decision remain my responsibility.


I do not claim to have compiled, executed, benchmarked, or reproduced a change unless the article or its accompanying research record explicitly states that I did so.


Corrections


Technical articles can contain mistakes or become incomplete as projects continue to change.


Corrections are welcome when a published fact, code path, number, date, attribution, or technical explanation appears inaccurate.


Material corrections may be added to the article with an explanatory note.


Independence


Resonetic Lab is not affiliated with the companies, repositories, maintainers, or contributors discussed on this site.


Any sponsorship, paid placement, affiliate relationship, or other material connection affecting an article will be disclosed clearly. No such relationship should be inferred merely because a company or project is covered.

Popular posts from this blog

AMD Is Trying to Turn Kernel Diversity Into One Software Asset

The first broad integration was rolled back, but the direction of the software stack is difficult to ignore The GPU software race is often described as a contest over who can write the fastest kernel. That is only part of the problem. A company may have several teams capable of producing high-performance matrix-multiplication kernels. Some may work through template libraries. Others may use compiler-generated code, handwritten assembly, or model-specific optimization stacks. The existence of those kernels does not automatically create one coherent platform. They still need to be: discovered validated matched to the correct problem given the correct arguments launched through a stable runtime and delivered through a reliable software package Recent public code changes inside AMD’s software ecosystem showed an attempt to connect these layers more directly. The central idea was to allow hipBLASLt’s GEMM selection system to choose kernels created by multiple internal kernel technologi...
Read more

PyTorch #188031 — Why Did Forward Use 64-Bit Indexing While Backward Still Used uint32_t?

PyTorch Spatial Softmax, Part 1 of 3 — An asymmetric indexing contract and the patch that aligned it A recent PyTorch change fixed a 64-bit indexing problem in the spatial softmax backward path. The bug was not in the softmax formula itself. It was in the width of the integer used to calculate memory locations. For the same large tensor, the forward path already selected either 32-bit or 64-bit indexing based on the input size. One backward path, however, continued to calculate sizes, strides, and offsets using uint32_t . That created a possible split in behavior: Forward → 64-bit address calculation → accesses the intended elements Backward → 32-bit address calculation → offset wraparound → gradients read from or written to different locations A tensor could therefore complete the forward pass correctly while the corresponding backward kernel could no longer represent every address in that tensor. The changes described in PyTorch #188031 were later landed in PyTorch’s main branch. S...
Read more

NVIDIA CUTLASS #3017 — Why load() and store() Mapped the Same Tile Coordinate to Different Addresses

CUTLASS #3017, Part 1 of 3 — An asymmetry in address calculation and the patch that fixed it In February 2026, while reading through NVIDIA CUTLASS’s RegularTileIterator<layout::PitchLinear> implementation, I noticed an odd asymmetry. load() and store() accepted the same tile coordinate, yet they calculated the corresponding memory address differently. The difference was a single line. load() divided the contiguous coordinate by kElementsPerAccess . store() did not. When each memory access handled only one element, the difference remained invisible. But in vectorized paths, where a single access handles multiple elements, the same logical tile coordinate could resolve to two different physical addresses. I reported the issue as CUTLASS Issue #3017. The missing division was later added to store() in PR #3049. CUTLASS and tile iterators CUTLASS is NVIDIA’s open-source library for high-performance CUDA linear algebra. It provides C++ template abstractions for composing GPU ope...
Read more