Contact

Contact


For questions about Resonetic Lab, factual corrections, missing sources, attribution, technical errors, or website issues, you can contact me through GitHub or email.


GitHub: red1239109-cmd


Email: red1239109@gmail.com


Corrections


I welcome corrections when a published fact, number, date, code path, benchmark description, source attribution, or technical explanation appears to be inaccurate.


When submitting a correction, please include:


- The title or URL of the article

- The statement that may be inaccurate

- The relevant source, code location, test, or documentation

- A brief explanation of the proposed correction


AI Disclosure


I use AI tools to assist with research organization, source comparison, drafting, and editing.


AI output is not treated as a factual source.


The final selection of evidence, technical interpretation, contract analysis, review verdict, and published framing are based on my own judgment and review of the available primary sources.


Resonetic Lab does not claim that code was compiled, executed, reproduced, or benchmarked locally unless the relevant article explicitly says so.


Independent Publication


Resonetic Lab is an independent publication and is not affiliated with the companies, repositories, maintainers, or contributors discussed on the site.


The site does not provide official technical support on behalf of the projects it covers.


Please do not send passwords, API keys, private source code, confidential company information, or other sensitive material through email or public GitHub channels.

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