sycl: Q5_K reorder MMVQ/dequant + Q8_0 reorder MMVQ path

[aicss-genai]

Overview

Authors

• @unrahul
• @ctao456
• @malsbat
• @YuningQiu
• @vvravi1
• @zhiqitao-intel

Extends the reorder-quantized codepath to Q5_K (new) and adds a reorder
MMVQ kernel for Q8_0.

• Adds block_q_t<GGML_TYPE_Q5_K> specialization with layout [qs (QK_K/2 per block)] [qh (QK_K/8 per block)] [scales] [dm] and matching get_block_offset / get_d_offset.
• Adds reorder_qw_q5_k (weight reorder), reorder_mul_mat_vec_q5_k_q8_1_sycl (MMVQ kernel), dequantize_row_q5_K_sycl_reorder and the reorder variant of dequantize_block_q5_K.
• Wires Q5_K into ggml_sycl_supports_reorder_mul_mat_sycl, ggml_sycl_supports_reorder_mmvq, and the reorder_qw dispatch.
• Adds reorder_mul_mat_vec_q8_0_q8_1_sycl and inlines reorder_vec_dot_q_sycl<Q8_0>::operator() (removes the small vec_dot_q8_0_q8_1_impl helper).
• Adds dequantize_q8_0_reorder and dequantize_block_q8_0_reorder helpers used by the Q8_0 reorder MMVQ path.

Uses the existing g_ggml_sycl_use_async_mem_op flag (default off in master); no dependency on #22066's async-toggle change.

Additional information

Split from #22066 per reviewer request for independent review.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: Yes. This work was partially produced with an agentic engineering approach: agents surface issues and explore experiments while engineers identify and reject candidates using domain knowledge. Human feedback involved.

[ggml-gh-bot]

Hi @aicss-genai, thanks for your contribution!

Per our contribution guidelines, the automated PR checker found the following issue(s) that need your attention:

• Multiple open PRs from a new contributor: We limit new contributors (those without a previously merged PR) to 1 open PR at a time. You currently have 7 open PRs.

---

Please note that maintainers reserve the right to make final decisions on PRs. If you believe there is a mistake, please comment below.