本周进展 1. 完成了 rocBLAS-4.1 的 ebuild，踩到了三个坑（cmake 版本问题 <https://bugs.gentoo.org/804181>，cmake 生成的 build.ninja 语法问题，TensileCreateLibrary 在 src_configure 阶段读取 LibraryLogic 生成 TensileManifest 后在编译阶段又花费大量 CPU 重新读取 LibraryLogic）；完成了 rocBLAS bundle Tensile at build time. 还未推到上游。 2. 重新检查了 hip-4.2 中的 patch，去除了不必要的成分。还未推到上游。 3. 更加仔细阅读了 Tensile 的文档。 4. 社区另一位开发者 fuga15 独立完成了包括 rocBLAS 等数学库在内的大量 version bump 与 bug fix 的工作，计划进行 review、比对、整合。
下两周计划 1. review fuga15 的 PR，整合 ebuild push to upstream 2. 完成 pytorch 的升级与测试 3. debug cmake 版本的问题 另外，进一步理解了 rocBLAS 编译过程中的 Tensile 发挥的作用（见 https://github.com/ROCmSoftwarePlatform/Tensile/wiki/TensileCreateLibrary）： Tensile 是为 benchmark-driven 的 GEMM 后端。相同的矩阵乘法在设备上可以有不同实现，Tensile 可以生成各种实现方案并跑 benchmark 挑选出最优方案。流程如下 1. 给定 GEMM 问题，生成一系列解决方案 (具体运算参数 与 kernel)，benchmark，保存 performance data，挑选 winning kernel 的相关参数保存，成为 LibraryLogic。这一部分已经由 ROCm 团队完成（提供官方支持的硬件的 LibraryLogic），打包在 rocBLAS 源代码中。 2. 构建 rocBLAS 时，调用 TensileCreateLibrary 读取已经准备好的 LibraryLogic，将其编译为 kernel 并打包成 code object，然后生成供 rocBLAS 调用这些 kernel 的 API （tensile library） 与数据库（存储 kernel 的参数信息）。 在 <=rocBLAS-4.0 时，读取 LibraryLogic (Ryzen 5800X 耗时 4min)、编译 kernel (耗时更长)、编译 tensile library (耗时更长) 统一由 src_configure 阶段的 TensileCreateLibrary 一个命令完成。从 rocBLAS-4.1 起，src_configure TensileCreateLibrary 带有命令行选项 --generate-manifest-and-exit，在读取完 LibraryLogic 后生成 TensileManifest.txt 后退出；构建阶段调用完整 TensileCreateLibrary，会重新处理一遍 LibraryLogic，并编译 kernel。这意味着， src_configure 阶段的读取过程较为冗余，但是目前还没有找到去除的方法（尝试去除会导致 configure 失败），而且该冗余还是很耗费 CPU 时间的。 -- 您收到此邮件是因为您订阅了 Google 网上论坛的“TUNA 主邮件列表”群组。 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到tuna-general+unsubscr...@googlegroups.com。 要在网络上查看此讨论，请访问 https://groups.google.com/d/msgid/tuna-general/CALxt-nSu0uVEh0Rbp%3DnbSNeQ3pTnu-nKM9sqDMSGuj%3DvaDTbGw%40mail.gmail.com。
