[ET-VK][Adreno] Non-deterministic conv2d output for c_out in {168,176,184,192}; clean on Mali
维护者通常 1 天内回复
@SS-JIA 已经在做这个了。
开始于 2026年8月24日。
评估
这个 Issue 还没有评估数据。
描述
🐛 Describe the bug
On Adreno, a single Conv2d lowered to the Vulkan delegate produces a different result on almost every execution, for a specific band of output channel counts. Identical .pte, identical input, same already-encoded command buffer replayed in one process.
Probe: Conv2d(48, c_out, 3, padding=1, bias=False) on a (1, 48, 64, 64) input, 200 in-process replays per run, order rotated across runs, cool device.
| c_out | excess distinct outputs | replays | runs with any deviation |
|---|---|---|---|
| 144 | 0 | 1600 | 0 / 8 |
| 160 | 0 | 1600 | 0 / 8 |
| 168 | 1142 | 1800 | 9 / 9 |
| 176 | 427 | 800 | 4 / 4 |
| 184 | 770 | 1000 | 5 / 5 |
| 192 | 772 | 1200 | 6 / 6 |
| 200 | 0 | 1400 | 0 / 7 |
| 224 | 0 | 600 | 0 / 3 |
Perfect separation. Every run of every c_out in {168, 176, 184, 192} deviates; no run of {144, 160, 200, 224} deviates across 5200 replays.
The band lies inside the im2col/GEMM convolution path: should_use_conv2d_im2col() routes any conv with c_out >= kIm2colMinCOut (128) there. Forcing that function to return false, so the direct conv2d shader is used, makes all of these deterministic. Note 160 and 200 are also in that path and are clean, so it is a size band inside the path, not the threshold itself.
This is very likely an Adreno driver or hardware problem, not an ExecuTorch bug
Three independent checks point away from ExecuTorch:
- A different GPU vendor is clean. The same binaries and the same
.ptefiles on a Galaxy S10+ (SM-G975F, Exynos 9820, Mali-G76, Android 12): all eightc_outvalues, 200 replays each, zero deviations. This is the strongest signal, becauseshould_use_conv2d_im2col()returnsgraph.device_is_mali() || c_out >= kIm2colMinCOut, so on Mali every conv takes the im2col path, including 144 and 160 which do not on Adreno. If the im2col shader itself were wrong, Mali should have been the worse device.
Confirmed at the application level as well, not just withexecutor_runner: a demo app built from the stock Vulkan backend runs both object detection (YOLO26) and image classification (EfficientNetV2-S) on the S10 with correct and stable results.
Separately, and worth knowing for anyone weighing the Vulkan delegate on Mali: on this S10 the Vulkan delegate is close to 2x slower than the XNNPACK equivalent for the same models. That is the opposite of the Adreno device, where Vulkan is clearly faster. The S10 is a 2019 part so this is not necessarily representative of current Mali hardware, but it does mean the delegate is fast on the GPU where it is incorrect and slow on the GPU where it is correct.
- Output is numerically correct on Mali, not merely stable. Exporting a Vulkan
.pteand a CPU.ptefrom the same model instance and comparing both against the eager reference gives 9.9e-07 (Vulkan) and 3.6e-07 (CPU), i.e. fp32 rounding. - Khronos synchronization validation reports zero hazards on the failing workload (layer injected into a debuggable app via
gpu_debug_layers, sync validation confirmed active by the layer's own settings message). NoSYNC-HAZARD, no VUID errors.
So the return false workaround most likely helps by avoiding whatever the Adreno driver miscompiles, rather than by avoiding an incorrect shader.
Reproducing
Counting distinct md5 of executor_runner stdout across repeated process launches is a poor measure: it is noisy, and on this device the failure rate of the related issue #21939 depends strongly on GPU power state. Patch executor_runner to dump outputs on every iteration of --num_executions (stock writes only the last), then count distinct outputs across in-process replays. This one is stable and reproduces at 215 to 262 MHz on a cool device, so unlike #21939 it is not sensitive to clock.
Possibly the same underlying defect as #21939, which is also Adreno-only but low-rate and power-state dependent.
Versions
ExecuTorch 1.4.1. Failing: Galaxy S26 Ultra (SM-S948B), Adreno 840v2. Clean: Galaxy S10+ (SM-G975F), Mali-G76.
- 主要语言
- Python
- 星标
- 5.1k
- 派生
- 1.2k
- 平均合并
- 2 天 10 小时
- 30 天内合并 PR
- 632
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
pytorch/executorch 的其他 Issue
-
Portable remainder kernel: wrong sign for integers and float64 rounded to float可能已有人在做 @JakeStevens 于 1 天前认领。 未关闭bug module: kernels triaged
难度 2/5 1-3 小时 新手友好度 82/100
pytorch/executorch#23682 · 已指派 2 人 ·
维护者通常 1 天内回复
-
enhancement triaged
难度 2/5 半天 新手友好度 68/100
pytorch/executorch#21640 ·
维护者通常 1 天内回复
-
macOS Python wheel _portable_lib has non-relocatable libtorch rpath可能已有人在做 @shoumikhin 今天认领。 未关闭
pytorch/executorch#23742 · 已指派 1 人 ·
维护者通常 1 天内回复
-
invalid module: doc
难度 3/5 1-2 天 新手友好度 35/100
pytorch/executorch#23706 · 1 条评论 ·
维护者通常 1 天内回复
-
Portable floor_divide returns non-whole numbers for floats and wrong values for a zero divisor可能已有人在做 @JakeStevens 于 1 天前认领。 未关闭bug module: kernels
难度 3/5 1-2 天 新手友好度 52/100
pytorch/executorch#23684 · 已指派 1 人 ·
维护者通常 1 天内回复
查看 pytorch/executorch 的全部 Issue
相似的 Issue
-
[Bug]: LangGraph Store sync put bypasses namespace validation可能已有人在做 @ktz03 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 72/100
volcengine/OpenViking#6050 ·
维护者通常 1 天内回复
-
[Bug]: Streamed /v1/chat/completions sends unredacted agent error text (keys) in the final chunk可能已有人在做 @rodricksz4h5 今天认领。 未关闭area/streaming comp/gateway P2 type/security
难度 2/5 1-3 小时 新手友好度 78/100
NousResearch/hermes-agent#138245 ·
维护者通常 1 天内回复
-
[oblt-aw][autodoc] Update user onboarding guide for mandatory trigger CODEOWNERS step可能已有人在做 @github-actions 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 66/100
维护者通常 1 天内回复
-
correction metadata
难度 2/5 1 小时以内 新手友好度 68/100
acl-org/acl-anthology#10378 · 1 条评论 ·
维护者通常 1 天内回复
-
cloudtrail_multi_region_enabled_logging_management_events fails when the advanced event selector has a custom name可能已有人在做 @12YYCCYY16 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
prowler-cloud/prowler#13033 ·
维护者通常 1 天内回复