[SYCL] Use native subgroup size for K-quant DMMV kernels on Intel

[PMZFX]

Summary

Use WARP_SIZE (16) instead of QK_WARP_SIZE (32) for the K-quant DMMV kernels on Intel SYCL, including the reorder variants now present on master.

These kernels were migrated from CUDA via DPCT and kept a 32-wide subgroup size. On Intel targets, native subgroup size is 16. DPCT flagged the original K-quant kernels with register pressure warnings recommending a smaller subgroup size, and the non-K-quant DMMV path already uses WARP_SIZE.

Each thread now processes both halves of the QK_K=256 block via a for (int im = 0; im < 2; ++im) loop. The inner dot-product computation is unchanged.

Updated scope

This rebased version covers 8 affected kernels in ggml/src/ggml-sycl/dmmv.cpp:

• dequantize_mul_mat_vec_q2_k
• dequantize_mul_mat_vec_q3_k
• dequantize_mul_mat_vec_q3_k_reorder
• dequantize_mul_mat_vec_q4_k
• dequantize_mul_mat_vec_q4_k_reorder
• dequantize_mul_mat_vec_q5_k
• dequantize_mul_mat_vec_q6_k
• dequantize_mul_mat_vec_q6_k_reorder

The original PR covered the five non-reorder K-quant kernels. Later master changes added K-quant reorder DMMV coverage, including Q3_K, Q4_K, and Q6_K, using the same old QK_WARP_SIZE=32 pattern. This rebase applies the same native-subgroup fix to all currently affected kernels.

Changes

• Kernel launch subgroup attributes switch from QK_WARP_SIZE to WARP_SIZE.
• Warp reductions switch from QK_WARP_SIZE / 2 to WARP_SIZE / 2.
• Each affected kernel processes both QK_K=256 halves in an explicit im loop, preserving total work.
• Old DPCT warning blocks for the original 32-wide K-quant kernels are removed.
• No other source files changed.

Current rebase verification

Rebased cleanly onto ggml-org/llama.cpp@8ed274ef46e2e6c073e5400af4286f53547c003e.

Test system: Intel Graphics [0xe223] via Level Zero, oneAPI 2026.0, AOT bmg_g21, Release builds.

• cmake --build build-kquant-rebase-icpx --target test-backend-ops llama-cli llama-bench -j 12: passed
• test-backend-ops -o MUL_MAT -b SYCL0 with GGML_SYCL_F16=OFF: 920/920 tests passed
• GGML_SYCL_PRIORITIZE_DMMV=1 GGML_SYCL_DEBUG=1 test-backend-ops -o MUL_MAT -b SYCL0: 920/920 tests passed
• cmake --build build-kquant-rebase-icpx-f16 --target test-backend-ops -j 12: passed
• test-backend-ops -o MUL_MAT -b SYCL0 with GGML_SYCL_F16=ON: 920/920 tests passed
• git diff --check: passed
• Static audit: no remaining QK_WARP_SIZE or stale DPCT1110 warning blocks in dmmv.cpp

Forced-DMMV real-model smoke tests using GGML_SYCL_PRIORITIZE_DMMV=1, llama-bench -p 64 -n 16 -r 1 -ngl 999 -dev SYCL0:

Quant	Model	pp64	tg16
Q2_K	Qwen3.5-27B Q2_K	120.43 t/s	15.58 t/s
Q3_K	gemma-4-26B-A4B UD-Q3_K_M	254.52 t/s	42.73 t/s
Q4_K	Qwen3.5-27B Q4_K_M	137.89 t/s	13.60 t/s
Q5_K	Qwen3.5-27B Q5_K_M	130.05 t/s	12.64 t/s
Q6_K	Qwen3.5-27B Q6_K	134.36 t/s	12.03 t/s

Previous PR testing

Intel Arc Pro B70 (Xe2/Battlemage, 32 GB), dual GPU, oneAPI 2025.3.3, Ubuntu 26.04.

Hang fix:

• EVA-Qwen2.5-72B Q4_K_M (dense, 80 layers): hangs on master during warmup, loads and serves correctly with this PR. 3 sequential prompts, all coherent.

Correctness:

• test-backend-ops -o MUL_MAT -b SYCL0: 911/911 passed, 0 failures

Performance (single GPU, sequential, Release, JIT, GGML_SYCL_F16=ON):

Model	Metric	Master	PR	Delta
Qwen3.5-9B Q4_K_M	pp128	1040 t/s	1128 t/s	+8.5%
Qwen3.5-9B Q4_K_M	tg32	54.6 t/s	55.3 t/s	+1.3%
Qwen3.5-9B Q8_0	pp128	1133 t/s	1079 t/s	-4.8%
Qwen3.5-9B Q8_0	tg32	47.6 t/s	47.5 t/s	-0.2%
Gemma4-31B Q6_K	pp128	327 t/s	327 t/s	0%
Gemma4-31B Q6_K	tg32	13.4 t/s	13.4 t/s	0%

Q8_0 is unaffected by this PR and already uses WARP_SIZE; pp variance is normal run-to-run variation. Previous testing by @arthw across Arc770, BMG580, iGPU (UHD), and PVC confirmed the original non-reorder changes were acceptable. The reorder kernels follow the same pattern.

[maxious]

Oddly I saw a TG improvement but not so much a PP with the B60 🤔
But PR looks good to merge 👍

Llama-2-7B Q2_K (dual GPU)

Test	Master (d12cc3d)	PR #21700 (839c7e2)	Improvement
pp512	1465.5 ± 23 t/s	1484.8 ± 30 t/s	+1.3%
tg128	15.6 t/s	21.3 t/s	+37.1%

Qwen3.5-27B Q2_K_XL (dual GPU)

Test	Master (d12cc3d)	PR #21700 (839c7e2)	Improvement
pp512	430.7 t/s	430.9 t/s	~0%
tg128	8.10 t/s	8.10 t/s	~0%

Qwen2.5-1.5B-Instruct Q2_K (single GPU)

Test	Master (d12cc3d)	PR #21700 (839c7e2)	Improvement
pp512	6931 t/s	6960 t/s	+0.4%
tg128	85.7 t/s	102.4 t/s	+19.5%

[NeoZhangJianyu]

It needs to be verified on more GPUs: iGPU, Arc7xx, BMG and Xe iGPU (meteor lake or newer).
I will feedback later.

Thank you!

[PMZFX]

Corrected the benchmark results; my original numbers compared builds with different GGML_SYCL_F16 settings, which inflated the pp numbers significantly.
I Re-ran with matched builds and updated the description.

@maxious thanks for testing on the B60. Your clean A/B comparison is what made the mismatch obvious. The real effect is a tg improvement on compute-bound K-quants (primarily Q2_K), not the pp speedup I originally claimed.

Updated title and description to reflect this.

The change is still architecturally correct; these are the only DMMV kernels still using the non-native subgroup size, and the DPCT register pressure warnings confirm 32 is too wide for Intel (at least, our cards).

[arthw]

We use 32 as warp_size in some kernel for better performance by test.

[arthw]

Sorry, it's my mistake to close this PR.
I reopen it.

[arthw]

The Arc770,BMG580, iGPU (UHD) are not impacted obviously.
PVC has 0% on PP, +12.5% on tg on Q2_K_XL.
PVC has 0% on PP, -4% on tg on Q4_K.

I think it's acceptable.

Thank you!

[arthw]

It's good job.

The sub-group size 16 is more useful on Intel GPUs.
The legacy code use 32 is based on test result.

Based on the latest driver and compiler, change them to 16 will make the code be clear and easy maintained.

It also approves the value 16 is better value to all Intel existed GPUs.

There are increase impact on B70/B60/PVC.
There is no impact to most of Intel old dGPU and iGPU (Arc770, BMG580, iGPU).
Except PVC has -4% of TG on Q4_K, there are no bad impact of performance on other Intel GPUs.

Thank you!

[PMZFX]

Rebased onto current master and expanded scope to also cover the Q4_K and Q6_K reorder DMMV kernels added in #21638.

After #21638 merged, dense Q4_K_M models (e.g. EVA-Qwen2.5-72B) hang during warmup on Intel GPUs. The reorder DMMV kernels were written against the unfixed QK_WARP_SIZE=32 code because this PR hadn't merged yet. This rebase applies the same for (im = 0; im < 2) restructuring to those two new kernels.

Testing on B70:

• EVA-Qwen2.5-72B Q4_K_M: hangs on master, loads and serves correctly with this PR (3 multi-turn prompts, all coherent)
• test-backend-ops -o MUL_MAT: 911/911 passed
• Benchmarks: no regressions on Q4_K_M, Q6_K, or Q8_0 (matched build flags, sequential, single GPU)

Updated the PR description with full details.

[arthw]

@PMZFX

This PR is approved.
Could you rebase the code to resolve the conflict for merge?

Thank you!

[PMZFX]

Hi @arthw, thanks for the approval.

I rebased the PR onto current master and resolved the conflict cleanly. While rebasing, I also updated the newly added Q3_K reorder DMMV kernel, so the PR now covers all 8 affected K-quant DMMV kernels: Q2/Q3/Q4/Q5/Q6 plus Q3/Q4/Q6 reorder.

I reran focused validation on Intel SYCL:

• test-backend-ops -o MUL_MAT -b SYCL0: 920/920 passed
• same test with GGML_SYCL_PRIORITIZE_DMMV=1: 920/920 passed
• same test with GGML_SYCL_F16=ON: 920/920 passed
• real-model forced-DMMV smoke tests passed for Q2_K, Q3_K, Q4_K_M, Q5_K_M, and Q6_K GGUFs

The branch is now mergeable and still only touches ggml/src/ggml-sycl/dmmv.cpp.