sycl: set fattn_vec_nthreads to 256 for Battlemage - #25205
Conversation
arthw
left a comment
There was a problem hiding this comment.
The idea to set different value for hardware is good.
But the method of hard code is not good.
In base code, there is framework to check the hardware type and set the parameter value in initial stage.
Is it possible to refactor the code by referring them?
code to check the hardware type:
In ggml-sycl.cpp
if (!(ggml_sycl_info().devices[ctx.device].hw_info.arch ==
gpu_arch::intel_gpu_acm_g10 &&
src0->type == GGML_TYPE_Q4_0)) {
use_dequantize_mul_mat_vec =
use_dequantize_mul_mat_vec && !use_mul_mat_vec_q;
}
Check the hardware and set parameter in initial stage:
In ggml-sycl.cpp
info.devices[i].max_wg_per_cu = info.max_work_group_sizes[i] / prop.get_max_compute_units();
info.devices[i].hw_info = get_device_hw_info(&device);
In this case, you could add info.devices[i].xxx = 128 for xe, 256 for xe2.
In the code, call info.devices[i].xxx to get the right value.
Thank you!
|
@Titaniumtown |
|
Yup! I will get on it, sorry, life has been busy. |
4d913bd to
dfae4d0
Compare
dfae4d0 to
d368c0a
Compare
d368c0a to
9315ed0
Compare
9315ed0 to
8a198f1
Compare
Currently detects lunarlake + battlemage / xe2 and sets the value to 256. Keeps default at 128, Intel's ARC Alchemist's prefered value.
8a198f1 to
add3f78
Compare
Launch geometry only: the non-contiguous concat kernel launched a single-lane work-group (1, 1, 1), now it will launch a (1, 1, SYCL_CONCAT_BLOCK_SIZE) one. SYCL_CONCAT_BLOCK_SIZE is defined in `ggml/src/ggml-sycl/presets.hpp`. Potential future improvement is using a similar dynamic value discovery to: ggml-org#25205 llama-bench (Arc Pro B70, Qwen3.6-27B-UD-Q4_K_XL, -fa on, q8_0 KV), on top of upstream master: pp2048 920 -> 1006 t/s (+9.4%)
Currently detects lunarlake + battlemage / xe2 and sets the value to 256. Keeps default at 128, Intel's ARC Alchemist's prefered value.
Currently detects lunarlake + battlemage / xe2 and sets the value to 256. Keeps default at 128, Intel's ARC Alchemist's prefered value.
Currently detects lunarlake + battlemage / xe2 and sets the value to 256. Keeps default at 128, Intel's ARC Alchemist's prefered value.
|
@Titaniumtown Could you check it? Thank you! |
|
@arthw has someone opened an issue for that? I don't have any Alchemist hardware to test with. |
|
No, I found it. |
|
@Titaniumtown |
Currently detects lunarlake + battlemage / xe2 and sets the value to 256. Keeps default at 128, Intel's ARC Alchemist's prefered value.
Currently detects lunarlake + battlemage / xe2 and sets the value to 256. Keeps default at 128, Intel's ARC Alchemist's prefered value.
100 commits, 8 SYCL. Conflicts in 6 files, 10 hunks. 7 union-merged (independent globals/switch-cases: our reorder_in_gemm + NVFP4 alongside their fa_onednn + Q2_K ggml-org#25064). 3 needed a call: - fattn.cpp: keep our env-gated MMA override FIRST, then upstream's oneDNN SDPA prefill FA (ggml-org#25222), then our decode VEC/TILE doors. Our decode + quantized-KV path stays ours; oneDNN takes prefill-shaped only. WARN: ggml-org#25222 has the RIG-HYGIENE ggml-org#26 pool_alloc use-after-free -- needs multi-turn 2-GPU garbage-token validation before trust. - fattn-vec.hpp: take upstream ggml-org#25205 Battlemage nthreads=256, preserve our is_vec_kernel=true arg (selects nsm geometry in launch_fattn). - dequantize.hpp q2_K: keep our f32-arithmetic dequant (NMSE 2.5e-7). test-backend-ops.cpp: v=4 was overloaded -- upstream ggml-org#25064 uses it for non-cont-a-last-2-dim, ours for transposed-b. Moved our transposed-b to bit 1<<4 so both coverages survive. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Overview
Adds a
GGML_SYCL_FATTN_VEC_NTHREADSoption which sets the VEC_NTHREADS option. This is useful when the hardware supports values different than 128.Additional information
For 1st gen Intel ARC Graphics, 128 is the native option. For 2nd gen Arc Graphics, 256 is what the hardware supports.
Requirements