Repository navigation
PTQ1_0 Vulkan fast path (#238) misses Xe3 iGPUs reporting minSubgroupSize == 8 (Intel Arc 140T / Panther Lake) #270
Description
PR #238 added a dedicated integer-dot shader for PTQ1_0 on Vulkan. It only fires when the device classifies as INTEL_XE2 (minSubgroupSize == 16). My Arc 140T (Panther Lake, Xe3) reports minSubgroupSize == 8, so it classifies as INTEL_XE1 and falls through to the blanket eIntelProprietaryWindows opt-out. The fast shader never runs.
Environment
- GPU: Intel Arc 140T (32GB), Panther Lake
- Driver: 101.8860, DRIVER_ID_INTEL_PROPRIETARY_WINDOWS
- vulkaninfo:
minSubgroupSize = 8 maxSubgroupSize = 32 integerDotProduct4x8BitPackedSignedAccelerated = true shaderIntegerDotProduct = true - Build: prism-b10735 (842b188), Windows, MSVC 19.51, Vulkan SDK 1.4.357
- Model: Ternary-Bonsai-2-27B-PTQ1_0.gguf
Repro
llama-cli -m Ternary-Bonsai-2-27B-PTQ1_0.gguf -ngl 99 -c 65536 -n 16384 --single-turn -p "..."
Result: 1.3 tok/s generation — matches the pre-#238 numbers that PR reported for Arc B390.
Root cause
ggml_vk_get_device_architecture() requires integerDotProduct4x8BitPackedSignedAccelerated for both INTEL_XE2 and INTEL_XE1 classification. ggml_vk_should_use_mmvq() only checks for INTEL_XE2 before allowing PTQ1_0 through. The shader needs the integer-dot flag, not the subgroup width, and INTEL_XE1 already guarantees that flag.
Fix
Add an INTEL_XE1 && device->integer_dot_product gate alongside the existing INTEL_XE2 check in ggml_vk_should_use_mmvq().
Result
Before: 1.3 tok/s
After: 8.8 tok/s (6.7x)
Branch with the patch: https://github.com/rriley-quorum/llama.cpp/tree/local/arc-140t-fixes (the vulkan: commit; ignore the sycl: commit, that's an unrelated local oneAPI-version workaround).
I'm happy to open a PR if this is a useful contribution.
Activity
bri-prism commentedon Sep 25, 2026
A data point from a Panther Lake Xe3 iGPU, which I think shows the 140T isn't Xe3.
Intel Arc B390, PCI ID
0xB080(Panther Lake, Xe3), Windows 11, driver 101.8724 (DRIVER_ID_INTEL_PROPRIETARY_WINDOWS),vulkaninfo:It classifies as
INTEL_XE2(minSubgroupSize == 16,ggml-vulkan.cpp~L478) and does get #238's fast path. At0324c6652, Ternary-Bonsai-2-27B PTQ1_0 runs tg128 13.07 t/s, vs 1.42 onprism-b10709(before #238); fully offloaded, 2 graph splits.So an actual Xe3 part reports SIMD16 and lands in the right bucket. As far as I know, the Arc 140T is the Arrow Lake-H iGPU (Xe-LPG+, derived from Alchemist, i.e. Xe1), not Panther Lake. Panther Lake's iGPUs are the Arc B370/B390.
minSubgroupSize = 8is what Xe1 reports, soINTEL_XE1is the correct classification for it, not a misclassification. It would be worth checking the 140T'sdeviceIDinvulkaninfo: Arrow Lake-H is0x7D51/0x7DD1.That doesn't change your fix, which still looks right to me: the integer-dot shader needs
integerDotProduct4x8BitPackedSignedAccelerated, andINTEL_XE1classification already requires it. Your measured 1.3 → 8.8 t/s says it pays on Xe-LPG+ too. It just reframes the change as "extend the PTQ1_0 fast path to Xe1 iGPUs with accelerated int-dot" rather than "fix Xe3 detection". I'd suggest opening the PR. If you do, atest-backend-ops test -b Vulkan0 -o MUL_MAT -p ptq1_0run on the 140T (withGGML_VK_DISABLE_MMVQunset; note it is presence-checked, so=0still disables it) would cover correctness on the new path.Tested with Claude Code.
rriley-quorum commentedon Sep 25, 2026
Thank you for the review! I'll open the PR.