跳转至

静态 GPU 代码对象验证

这些 收据 固定了所测量的运行时树、发布者 URL/摘要、实际命令、已完成答案和资源成本。下载的二进制文件、工具链和完整 Evidence 包仍保留在 Git 之外。

正确性

NVIDIA CUDA 12.9.1 再分发存档已根据其发布者清单进行验证。nvcc 12.9.86 为 sm_80 和 sm_90a 编译了一个小型自有内核,包含未压缩、按大小压缩和按速度压缩的 fatbin。cuobjdump 12.9.82 独立确认了偏移 0/8 处的两个参数,大小分别为 8/4、12 个参数字节、10 个物理寄存器和与架构相关的共享内存。单独的 PTX/CUBIN 以及一个主机 ELF 对象测试了相同的解析器边界。

Clang 14 生成了一个 gfx900 HIP 包和一个 AMDGPU ELF 对象;llvm-readelf 提供了 MessagePack 元数据 oracle。LLVM 19 的 offload bundler 生成了一个真实的 CCOB v2 Zstd 包。所有九个生产者工件都在最终运行时源代码上被重新读取,并实现了完整的负载覆盖。CCOB v1/v3 和 zlib 拥有可移植的边界夹具,而非真实的生产者验证。

已发布的 Linux 和 Windows nvJPEG 12.4.0.76 工件各包含 165 个 CUBIN 和 10 个 PTX 负载,横跨 15 个目标声明,共 3,968 个内核声明。独立提取匹配了全部 165 个已解码的 CUBIN 哈希和全部 10 个 PTX 字节序列;cuobjdump 资源输出匹配了全部 3,720 个原生内核名称/寄存器/共享内存元组。评审前 MCP 工作流使用 Linux sm_100 子集的 248 个完整内核事实与之前的 oracle 事实进行了复核。评审前公开 CLI 分析了整个 Windows DLL,导出了完整 Evidence,并精确重现了所有先前已验证的事实。

Windows 验证在 Linux 上运行:LLVM 独立识别了 PE 节区坐标,cuobjdump 消费了其提取出的 fatbin。cuobjdump 无法直接识别该 DLL。这并不能确立 Windows 运行时行为、GPU 执行、主机启动关联或旧版 AMDGPU YAML 支持。

初始完成的 MCP 工作流

两个全新的 stdio MCP 会话仅分析了同一 Linux 库中的 sm_100,保留了 176 个清单对象和 248 个内核事实,查询了同一命名内核,导出了 Evidence,并重复了三次历史查询。完整变体返回了所选目标报告;所选变体返回了同调用内核页面。两者都保留了完全相同的答案:一个 168 字节的参数、31 个物理寄存器和 9,216 个共享字节。

成本 完整报告 所选页面
使用的输入声明 + 三个主要调用,估计 token 数 406,862 26,106
所有输入声明 + 主要调用,估计 token 数 635,381 254,625
完整通告目录 + 全部六个调用,估计 token 数 1,475,258 1,094,502
进程族经过时间(秒) 15.492 15.443
进程族 CPU 时间(秒) 18.220 18.074
采样峰值进程族 RSS 字节数 1,139,601,408 1,321,566,208
首次检查毫秒数 8,572 8,810
三次热保留页调用,毫秒 10.7 / 10.6 / 9.8 12.0 / 11.4 / 10.6

Tokenx 估计包括通告的模式、参数和完整 SDK 回复;它们不是实际的模型用量。文本和结构化回复表示都被计算在内。初始化和 JSON-RPC 封装未测量。完整目录发现大幅降低了整体百分比节省效果。

这些是同一实现上的工作流变体,而不是前后解析器速度基准。Node 编译缓存被禁用,但 OS 缓存和无关的主机负载未受控制。未确立任何普遍的延迟、CPU 或内存改进。所选工作流在此配对中使用了更多峰值内存。早期的一次全目标完整回复超过了现有传输保护;该不完整尝试已从已完成比较中排除。

完整的 Windows DLL CLI 任务耗时 4.064 秒 / 4.909 CPU 秒 / 503,459,840 峰值进程族 RSS 字节。所有已分析并完成的任务都保持在 8 GiB 和 420 秒的保护限制内,使用了两个 CPU 亲和性。峰值 RSS 每 20 毫秒对负载后代求和,且为近似值;观察者被排除在外。

回归检查

  • 初始聚焦运行在 19 个文件中通过了 265 项测试:GPU 领域/编解码器/解析器用例、公共 CLI/MCP、保留视图、输出配置、取消与清理,以及共享的 ELF/PE Go、Rust 和 IL2CPP 消费者。
  • 在目录/仅文档后续工作之前,完整静态检查已通过;其收据记录了 6,866,296,832 峰值进程族 RSS 字节。最终 CI 运行使 PR 通过。
  • 在修复缺失的目录所有权、翻译后的 README 链接和新的 MessagePack 依赖通知后,文档/目录/许可证检查已通过。
  • 早期一次合并的模式运行在两个 CPU 上遇到两次 30 秒超时。隔离的规范模式套件在未提高限制的情况下通过了全部 15 个用例。这被记录为成功的隔离,而非已证实的基线失败。

保留缓存通过 WeakMap 限定于不可变的 Evidence;历史页面不会重新打开文件。实时检查总是流式处理新的全文件哈希,并重新验证描述符/路径。不声称存在实时状态新鲜度缓存。

评审后续

在 36b87ed,公共 CLI 重现了两个评审发现:在真实的 Clang 生成的独立对象中选择 amdgcn-amd-amdhsa--gfx900 返回零个内核并提示未知目标,而格式错误的 --targets JSON 在 view 问题路径被报告。

在 09c6062,AMD ELF note 解析负责目标发现和预准备的内核声明。Inventory 在选择前读取这些有界 notes;选中的分析复用它们,无需两次解码 MessagePack。在读取前,编码后的 note 字节总量限制为 8 MiB,并保留现有的每值/深度限制;解析后的 JavaScript 表示会扩展到超出该源字节数。预准备的声明仅存在于当前载荷检查期间。命名 CLI 选项解析还会将实际解析后的输入提供给 schema 诊断。

真实的公开 CLI 现在会清点 gfx900 目标,在选中时返回生产者的 1 个 kernel / 2 个参数 / 12 字节参数区 / 6 SGPR / 2 VGPR,并为一个不同目标保留未选中对象且不包含内核事实。这三个完整 CLI 任务合计耗时 5.974 秒 / 6.951 CPU 秒 / 383,623,168 个采样峰值 family RSS 字节,包括 Python 任务驱动程序。所有九个生产者工件都以完整载荷覆盖被重新读取。

审查回归运行通过了四个文件中的 35 个用例,包括公开 CLI、MCP、元数据容量和清理。在添加由 CI 发现的缺失 CLI analysis 选项描述后,另有 10 个产品目录用例通过。此前的成对 nvJPEG 测量仍固定在其原始运行时;这些后续工作不会建立新的 CUDA 性能结果。

有界元数据与部分事实审查

在 ad1e17a 的最新资格验证基于 main 5241597 重新基线,同时保留 Rust 和 GPU 的保留视图。九个文件中的全部 70 个聚焦用例均通过,包括两种公开 CLI/MCP 工作流;单独的 SDK 转换规范 schema 套件全部 15 个用例通过。

CUDA 解析共享一个总计 262,144 条 record/symbol 访问预算、128 MiB 节读取预算和 16 MiB 序列化大小记账预算,用于索引事实。相同作用域的字节范围和重复寄存器值会在索引增长前被合并;冲突值则保留。已解析的参数元数据被复用。公开 CLI 处理了一个 861,896 字节的 CUBIN,其中包含 1,024 个别名指向 65,536 条记录,并保留了正确的物理计数。旧的 6700 万条记录扩展是源派生的;它没有被运行到耗尽。

解码器覆盖现已达到对象、报告和目标页面:缺失的 CUBIN 符号表和未知节名称仍为部分覆盖。AMD note 解析使用带标签的 Result,在后续畸形、容量超限、不支持或中断的读取中保留先前已解析的 notes;保留的内核事实会在原始失败传播前发出。独立 PTX 识别可继续超出 64 KiB 快速路径,直至其实际的 16 MiB 文本预算,并复用完整探测字节。不支持/溢出的寄存器数量保持为 null,而不是低总数。

公开 CLI 在别名用例之外,还验证了一个 AMD 有效 note/截断 note 输入和一个带有 70 KiB 前导注释的 PTX 文件。这三个任务合计耗时 5.132 秒 / 6.222 CPU 秒 / 405,835,776 个峰值 family RSS 字节,包括 Python 驱动程序。回归用例还覆盖独立和捆绑 AMD 对象中的无效 MessagePack 和不支持扩展名。

修订后的 Windows DLL 工作流保留了全部 165 个已解码 CUBIN 哈希、全部 10 个 PTX 字节标识和全部 3,720 个本机内核事实。独立统计 cuobjdump 提取的 PTX 中的寄存器声明,验证了全部 248 个 PTX 内核;20 个内核总计现在正确包含之前遗漏的声明。这是一个虚拟声明预言机,而非物理分配或 GPU 执行。Linux sm_100 工作流仍然与全部 248 个经独立检查的本机内核事实匹配。所有九个真实生产者工件都保留完整载荷覆盖。

最新的完整/选中 MCP 配对执行了相同的六次调用,并回答了与初始配对相同的问题。回执保留两个测量阶段。

开销 完整报告 选中页面
已使用的输入声明 + 主要调用,估算 tokens 407,368 26,612
所有输入声明 + 主要调用,估算 tokens 636,495 255,739
完整目录 + 全部六次调用,估算 tokens 1,480,698 1,099,942
进程族耗用秒数 15.487 15.923
进程族 CPU 秒数 18.404 18.760
峰值 family RSS 字节 1,251,254,272 1,201,774,592

这些仍然是 tokenizer 估算和同代码工作流变体。最新的单次配对不确立普遍的延迟/CPU/内存改进;OS 缓存和主机争用仍不受控。Windows CLI 重新运行在 4.078 秒 / 4.880 CPU 秒 / 498,380,800 个峰值 family RSS 字节内完成。

主 CI 独立复现了浏览器终止和 WASM 可选输入断言失败,未涉及 GPU 变更。已取消的 fail-fast 分片不计为通过。这些基线失败不属于此功能修复范围。

目标声明与 CUDA ABI 资格认定

最新代码 f5be46f 基于 main f801b2f。Inventory 和 payload 目标声明保持分离,即使在选定字段时,对象页面中仍保留类型化一致性和检查覆盖。不匹配的外层/内层基础目标仍为部分覆盖,并标注受影响的 kernels;仅 CUDA 基础目标一致并不能确立特性配置上的一致。目标过滤器选择 inventory 声明,未检查的内层目标保持未知。

独立和未知 ID 捆绑的 AMDGPU 文件在过滤前使用相同的有界目标发现所有者。可移植控制用两个分隔符、一个分隔符和不透明 HIP ID 包装同一个真实 Clang ELF。随后所有三种 inventory 精确目标 CLI 工作流都保留经验证的 kernel。它们是替代包装控制,而非对实际旧编译器生产者的验证。

共享的固定 ELF 头所有者现在保留 OS ABI。NVIDIA 发布的 CUBIN 包含不同的 0x33 和 0x41 标志布局。早期的仅低字节解释错误地为 55 个现代负载生成了 sm_2;那个尝试性的目标检查实现及其计时数据已被取代,仅作为诊断证据,而非经正确性认证的基准。符合 ABI 的解码器保留原始标志和精确的固定头坐标,并将无法识别的模式保持为未知。在导入可移植 Evidence 时会检查头所有权。

所有 165 个已发布的 Windows CUBIN 目标和头值均与 cuobjdump 提取的文件进行了核对:110 个使用 OS ABI 0x33,55 个使用 0x41;不再存在误冲突。所有 3,968 个已修正的内核事实和 10 个 PTX 字节身份均与此前的独立 oracle 匹配。九个真实的生产者工件保留了完整的负载覆盖。不支持的布局控制会保留其头,并使默认 MCP 摘要中的未知目标发现变为部分。

在共享头变更之后,九个文件中的 251 个用例通过,包括 Go/Rust/IL2CPP 消费者、GPU CLI/MCP 以及来源伪造。最后一次不确定性传播检查通过了 46 个公共/边界用例。单独的 SDK 转换后的规范 schema 套件在当前基线上通过了全部 15 个用例。

最新的合格完整/精选配对保留相同的 sm_100 问题、答案和六次调用工作流。它运行于 21eaa0d,位于最终的仅未解决发现守卫之前。

Cost Complete report Selected page
已使用的输入声明 + 主要调用,估计 tokens 418,967 26,653
所有输入声明 + 主要调用,估计 tokens 648,242 255,928
完整目录 + 全部六次调用,估计 tokens 1,493,041 1,100,727
进程族耗时秒数 21.307 24.604
进程族 CPU 秒数 23.538 26.454
进程族峰值 RSS 字节数 1,146,519,552 1,341,333,504

精选回复节省上下文,但不能证明更快的分析。最新配对在精选交付上使用了更多的耗时/CPU 时间和峰值内存;在保留的试验中可以看到变异性。新进程生命周期受控;OS 缓存、频率和无关负载不受控制。相同代码的诊断计时重复测试差异很大,未推断出任何原因或持续加速。tokenizer/客户端范围以及省略的初始化成本仍与上述相同。

最终 Windows CLI 任务耗时 5.446 秒 / 5.916 CPU 秒 / 498,192,384 进程族峰值 RSS 字节。六个 HIP 包装器 CLI 任务耗时 15.696 秒 / 16.427 CPU 秒 / 382,410,752 进程族峰值 RSS 字节。所有已完成任务均保持在 8 GiB 进程族守卫之内。

负载准入与 PTX 不确定性后续

在 893e04d,PTX 解析拥有类型化的按内核覆盖范围,以及未知参数布局、共享声明和虚拟寄存器计数的限制。Inventory 将该覆盖范围转发给对象、报告和历史页面。Inventory 中旧的仅寄存器解释已被移除。

一次 67 个用例的聚焦运行在五个文件中通过,包括解析器、公共 CLI/MCP、提供者边界和生命周期测试。三个源准入用例也通过了(其中一个与聚焦运行重叠)。NVIDIA ptxas 12.9.86 接受了一个指针参数 PTX 控制用例;公共 CLI 保留了其未知布局并报告了部分覆盖。一个由 cuobjdump 独立提取的已发布 nvJPEG 示例使用了 .param .u64 .ptr .align 1;这仍不属于受支持的布局解释。

修订后的 Windows DLL 报告保留全部 176 个对象事实字段、全部 3,968 个内核事实字段以及全部 10 个精确 PTX 字节身份。八个 PTX 对象和 59 个内核现在以部分覆盖和新增限制的方式暴露其先前存在的未知参数布局。此前对这些 PTX 对象的完整负载覆盖声明已被取代;解码后的数值事实不变。九个真实的生产者工件仍保留完整的负载覆盖。

共享的工作所有者现在在读取/分配前一次性保留未压缩的负载输入,并以原子方式保留压缩输入和解码输出。CCOB 使用与负载分析和 AMD note 读取相同的准入所有者。该工作的额度为 512 MiB,每个输入/输出缓冲区 128 MiB。已准入的失败工作仍会计入额度。一个真实的稀疏 HIP 文件包含一个 128 MiB ELF 负载的十二个别名:文件读取插桩观察到四次完整负载读取和八次容量拒绝(未读取负载或解码摘要);此前的四个内核事实得以保留。CUDA 和 CCOB 的超大输出控制用例同样证明在读取压缩输入之前就会拒绝。旧的被拒绝别名重读是源自源代码的;它们并未被运行到资源耗尽。

九生产者测试耗时 1.148 秒 / 1.100 CPU 秒 / 122,732,544 进程族峰值 RSS 字节。指针 PTX 和已发布 DLL 的公共 CLI 任务合计耗时 10.102 秒 / 11.302 CPU 秒 / 512,335,872 进程族峰值 RSS 字节。聚焦运行耗时 142.441 秒 / 211.528 CPU 秒 / 3,478,200,320 进程族峰值 RSS 字节,包括所需的工件构建。没有资源守卫阻止这些任务。此前的 MCP 成本对仍固定在其测量修订版上;本次后续没有推断出新的加速。

三次验证器尝试在 JSON 记录中被保留为不成功:对 Evidence 捆绑包的错误裸记录假设、拒绝覆盖现有导出,以及一个过时的期望(即现已修正的 PTX 覆盖会保持完整)。成功的比较要求所有事实值和 PTX 字节匹配,同时显式检查预期的不确定性变化。

npm run check 在此源代码修订版上通过,包括类型检查/lint/格式化、模块边界和架构守卫:135.345 秒 / 266.563 CPU 秒 / 5,371,879,424 采样进程族峰值 RSS 字节;没有资源守卫停止。

npm run docs:check 也已通过,包括全部五个 README 一致性用例。

本页原文 Markdown:在 AtomGit 查看·内容源自开源项目 rea2/rea