basalt

出厂超频不会改变测量结果。这里的每个延迟都以周期为单位，这是流水线的属性，而不是时钟的属性；加速频率被记录在旁边，只是为了让墙钟时间比较仍然可能。这块板真正影响的是可复现性，这也是为什么 basalt measure --board 会记录它。

这种布局一经使用便自证其正确。在一个简单内核中，S2R 设置 write_barrier=0，而消费其结果的那条 IMAD 带有 wait_mask=0x01；LDCU.64 设置 write_barrier=1，依赖它的 STG.E 带有 wait_mask=0x02。每一对生产者与消费者都能一一对应，并且 nvdisasm 标注为 .reuse 的指令也设置了相应的复用位。

快速入门

无需安装 CUDA，也无需 GPU。工具链脚本会获取固定的可再分发组件，大小约 45 MB，无需管理员权限，也不会向您的 PATH 中添加任何内容。```bash git clone https://github.com/sunnypatell/basalt.git cd basalt python -m venv .venv && source .venv/bin/activate # Windows: ..venv\Scripts\Activate.ps1 pip install -e ".[dev]"

python scripts/fetch_toolchain.py # pinned ptxas + nvdisasm python -m basalt.cli doctor # verify both oracles end to end python scripts/verify_all.py # every control in this README, in order

或者作为包安装

pip install basalt-sass 会安装 CLI、库以及全部三个测量表， 且没有运行时依赖。如果机器上已经装有 CUDA，可以使用这种方式； 如果尚未安装，或想要复现测量结果，则应该使用上面的 checkout 方式。```bash pip install basalt-sass basalt doctor basalt verify kernel.cubin

从头重建指令数据库，或查询已提交的数据库：```bash python -m basalt.cli build-isa # harvest, probe, write src/basalt/data/isa/sm_120a.json python -m basalt.cli isa --stats python -m basalt.cli isa IMAD.WIDE.U32 # one form, with its measured field layout python -m basalt.cli isa --opcode QMMA # every form of one opcode

(empty)```console $ python -m basalt.cli verify nvjpeg.sm_120.cubin 25 kernels, 0 with an error 7984 instructions in 789 blocks, 11580 dependencies checked across blocks: 0 errors, 3 warnings pair data: 3957 pairings from 25634 kernels, 427 producers with enough observations to use latency model: measured on NVIDIA GeForce RTX 5070 Ti

CLI 能做到的一切都可导入，带有可运行示例的库接口 位于 docs/API.md。

还有两个让其余部分保持可信的校验机制。第一个需要显卡；第二个需要 随附的库，完全不需要硬件：```bash python scripts/roundtrip_corpus.py # reschedule all 441 corpus kernels, run both on the GPU

python scripts/fetch_toolchain.py --libs # ~1.2 GB, no admin, nothing on PATH python scripts/audit_shipped.py --libs third_party/cuda/13.3.1/libs

实测，而非假设

这里的数字由工具打印，并在干净的检出（clean checkout）下重新生成。上面的命令才是事实来源；这些表格只是快照。

指令数据库。 每个条目都承载着一个实际汇编出的编码以及生成它的编译器构建。

张量覆盖范围正是低精度硬件的所在之处：HMMA 和 IMMA，QMMA 涵盖 FP8、FP6 和 FP4 类型，包括非对称操作数对；携带每块指数的比例因子形式 QMMA.SF 和 OMMA.SF；稀疏 IMMA.SP；以及矩阵移动指令 LDSM、STSM 和 MOVM 的所有形状，包括转置变体。

延迟，基于 RTX 5070 Ti。 70 个 SM，每次拟合 R² ≥ 0.9998。测量方法是对依赖链计时并取斜率，链长度从编译后的 SASS 中读回，而非假设。

其中三项与 basalt 随附的假设模型相矛盾：DADD 被假设为 48，POPC 被假设为 4，每项转换被假设为 6，而实测往返为 24。

假设的延迟模型并非实测模型的轻微近似，这正是测量的全部意义所在。

零停顿（stall）并不是零周期。 它是一种独特的、安全的编码，用于等待未完成的结果，在一条已调度的指令仅需 4 个周期的情况下，它要耗费约 37 个周期。这就是为什么 ptxas -O0 会发出一个完全置零的控制字，而代码仍然能正确计算，只是大约慢了九倍。

它在语料库的每个内核上都与厂商编译器一致。 ptxas 从语料库构建的每个内核，都会在每一个进行调度的优化级别下，依据其自身的调度进行验证：30,421 条依赖，零错误。该扫描在每次推送时都会在 CI 中运行，这个项目犯过的每一个建模错误都是被它捕获的，而不是靠推理。

判定与芯片一致。 对于依赖生产者上的每一个可编码停顿，basalt 的静态答案与硬件实际计算的结果都一致，包括零停顿的情况。这一点是以测试形式维护的，而不是在此处断言。完整证据（包括确定所需停顿的三种独立方法以及过程中所做的修正）见 发现。

当它说某个调度不安全时，芯片也同意。 取厂商自己针对 233 个内核的工作调度，在每个内核中缩短一个真实依赖，然后将 basalt 的判定与 GPU 实际计算的结果进行比较：它判定为损坏的 79 个确实损坏，而 它判定为安全的调度均未计算出错误答案。这个数字最初是 34 个漏报，而不是 0，发现 说明了原因，以及修复它所带来的误报代价，因为一个只报告最终数字的扫描，其价值不如一个同时报告最初数字的扫描。

它也能分配控制位

验证器回答的是某个调度是否安全。调度器则基于同样的测量，回答一个安全的调度应该是什么样的：它丢弃 ptxas 产生的每一个控制位，计算自己的控制位，把结果交还给验证器，然后在 GPU 上将其与厂商版本的同一内核并排运行。

在显卡上对整个语料库运行，在每一个会生成调度的优化级别下，所有 439 个可比较的内核最终都由 basalt 自行算出的控制位，计算出了与厂商调度逐字节一致的结果。被排除的 2 个内核会读取时钟和网格 id，因此它们连自身都无法保持一致，发现 明确说明了这一点，而不是把它们并入某个百分比。

这种控制正是其余一切可信的原因。检查器和调度器读取同一个延迟模型，因此模型中的一个错误条目会同时满足两者，使它们彼此一致，而实际上两者都是错的。只有芯片在这件事上没有既得利益。调度器在七个手写内核上运行，很长一段时间内都是七战七胜；在三百个内核上运行，则发现了四十一个错误的；此后每一次模型修正都来自观察这个数字的变化。

这个循环正是真正 bug 的来源。花费在生产者与其消费者之间窗口之外的停顿毫无意义，而把它花在那里会让搜索最终得到一个仍然不足的程序。一个被固定到安全编码上的停顿被后续的 pass 覆盖，用一个小数字替换了保证。fp64 操作数占用寄存器对，而助记符中没有任何信息表明这一点，因此每个 fp64 依赖的一半对检查器和调度器都是不可见的。用作指令守护条件的谓词需要十三个周期，而同样的谓词作为数据读取时只需要五个周期，因为守护条件必须在指令发出之前就被解析。等待记分板并不能完全解决依赖：生产者仍有自己的一小段停顿，fp64 加法为两个周期，少一个周期就会静默地出错。这些都不是靠推理发现的；每一个都是通过运行输出并得到错误数字而发现的。

[!NOTE] 1.0，并明确说明其含义。 已完成的部分：两个 oracle（指令数据库，其字段已被证明可写；以及基于真实控制流图的冒险检查器）；在一款 SKU 上通过三种独立方法测量的延迟；一个能对每个可比较的语料库内核进行逐字节硬件往返验证的调度器；以及一项对 2,762 个已发布内核的审计，这些内核被排除在检查器读取的所有表格之外。未完成的部分：12 个因构造而无法运行的语料库内核，以及 2 个厂商输出不确定的内核，均已在发现中列出；十个操作码仍然带有假设延迟而非实测延迟，且它们在任何一份代码中都从未作为生产者出现；另外只测量了一款 GPU，发现 28 表明这影响比听起来小。当某些内容是推断而非测量得到时，工具会明确指出，而不会把它美化成为事实。参见 路线图 和 方法。

仓库布局