Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

[ET-VK] is_coopmat_eligible() disables cooperative matrix on all integrated GPUs

未关闭
  • 哪里不对？
#22,665 6 条评论 1 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@SS-JIA 已经在做这个了。

开始于 2026年9月10日。

评估

这个 Issue 还没有评估数据。

描述

enhancement module: vulkan needs reproduction
🐛 Describe the bug

is_coopmat_eligible() in backends/vulkan/runtime/graph/ops/impl/GemmCoopmat.h disables the cooperative-matrix GEMM path on every integrated GPU, regardless of whether the device advertises VK_KHR_cooperative_matrix:

inline bool is_coopmat_eligible(
    ComputeGraph& graph, const ValueRef out, int64_t M, int64_t N, int64_t K) {
  if (graph.dim_of(out) > 2) {
    return false;
  }
  const auto* adapter = graph.context()->adapter_ptr();
  return adapter->supports_cooperative_matrix() &&
      adapter->subgroup_size() == 64 && !adapter->is_integrated_gpu() &&
      graph.storage_type_of(out) == utils::kBuffer && M % kCoopmatTileM == 0 &&
      N % kCoopmatTileN == 0 && K % kCoopmatTileK == 0;
}

On an AMD Strix Halo (Radeon 8060S, RADV, GFX1151) every other condition is satisfied — the device reports cooperative matrix support and a subgroup size of 64 — but !adapter->is_integrated_gpu() rejects it. For reference, llama.cpp's Vulkan backend enumerates the same device as

Radeon 8060S Graphics (RADV GFX1151) (radv) | uma: 1 | fp16: 1 | bf16: 0 | warp size: 64 | matrix cores: KHR_coopmat

and uses coopmat on it.

A second condition, dim_of(out) > 2, separately excludes batch-1 transformer activations, which are (1, M, N). A tensor whose leading dimensions are all 1 has the same buffer layout as the 2-D tensor it wraps.

Is the integrated-GPU exclusion deliberate — guarding a known correctness or performance problem on APUs — or is it a conservative default? Nothing in the source or in #19009 says which, which is why this is a question rather than a PR.

What I measured

I removed both conditions locally (dropped !adapter->is_integrated_gpu(), and relaxed the rank check to permit leading dimensions equal to 1) and ran the V-JEPA 2 ViT-L encoder, 512 tokens, fp32, buffer storage. Identical .pte on both runtimes, so only the eligibility check differs:

graph stock coopmat enabled
heavily partitioned (73 delegate calls) 487.8 ms 427.2 ms (−12.4%)
single delegate call 141.3 ms 140.3 ms (no change)

Accuracy was neutral, measured over five different inputs against eager PyTorch:

stock coopmat enabled
relative L2 2.845% – 4.832% 2.807% – 4.757%
worst-token cosine 0.86150 – 0.98976 0.87001 – 0.99032

So on this device the exclusion does not appear to be guarding a correctness problem, and the gain is real but workload-dependent — it showed up on a badly partitioned graph and not on a well-partitioned one, which is consistent with GEMM being a larger share of the former.

Context for the motivation: this encoder runs at roughly 2.4 TFLOP/s on this part, about 16% of its fp32 peak, with the whole graph in a single delegate call — so the time is in the shaders rather than at the partition boundary.

I'm happy to send a PR if the exclusion turns out to be conservative rather than intentional. I did not open one directly because I can only test a single integrated GPU, and a device-class gate is exactly the kind of thing that wants broader validation than I can give it.

Versions
  • ExecuTorch b20f16a70b8d9d9953c7ab15c05a1f5584cc36ef (1.4.0a0); the code is unchanged on main at the time of filing
  • torch 2.12.1+cpu, Ubuntu 24.04
  • AMD Strix Halo, Radeon 8060S (RADV GFX1151), Mesa 25.2.8
  • EXECUTORCH_BUILD_VULKAN=ON, buffer storage, fp32

cc @SS-JIA @manuelcandales @digantdesai @cbilgin

主要语言
Python
星标
5k
派生
1.2k
平均合并
2 天 5 小时
30 天内合并 PR
491

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

pytorch/executorch 的其他 Issue

查看 pytorch/executorch 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。