Misc. bug: [SYCL] GET_ROWS returns wrong values or NaN on weights reordered by MUL_MAT #30428

Name and Version

llama.cpp master cbe28bb (13 Oct 2026). Also present in acestep.cpp's ggml fork (synced 7 Oct).
SYCL build: oneAPI 2026.1, icx/icpx, -DGGML_SYCL=ON
Hardware: Intel Arc Pro B60 24 GB, Level Zero driver 1.14.37020

Operating systems

Linux

Which llama.cpp modules do you know to be affected?

Other (Please specify in the next section)

Command line

Problem description & steps to reproduce

ggml, SYCL backend (ggml/src/ggml-sycl/getrows.cpp)

With GGML_SYCL_ENABLE_OPT=1 (the default), ggml-sycl reorders Q4_0, Q8_0, Q2_K, Q3_K, Q4_K, Q5_K and Q6_K weights in place the first time they're used in a small-batch MUL_MAT (8 tokens or fewer), and marks the tensor with extra->optimized_feature.reorder. GET_ROWS never checks that flag. If the same tensor goes through GET_ROWS afterwards, it decodes the reordered bytes as if they were normal blocks and returns wrong values or NaN.

You need one tensor used by both ops on the device, which is what happens with tied embeddings when the embedding isn't kept on the CPU. llama.cpp mostly avoids this because its input embeddings stay on the CPU and a tied output gets its own copy, but other ggml-based programs run into it.

Real-world case. acestep.cpp's 4B LM (Q8_0, tied embeddings). Seed 42 with a 240 s request, which should produce about 1,200 audio codes:

Full logs: ServeurpersoCom/acestep.cpp#54

Minimal repro. One graph with mul_mat(w, x) where x is a single column, followed by get_rows(w, ids) on the same w, compared against CPU. I've written this up as a test-backend-ops case (test_get_rows_after_mul_mat) and will open a PR with it and the fix.

1. Build with -DGGML_SYCL=ON.
2. Add the test case and run test-backend-ops -b SYCL0 -o ADD.

On unpatched master it fails for all 7 types on SYCL. Q8_0 and Q6_K give NaN, the rest give wrong values. The same test passes on Vulkan.

AI disclosure: the investigation was done with Claude Code Assistance. I've verified the results on my own hardware.

First Bad Commit

No response

Relevant log output

[GET_ROWS] NaN at index 608 (SYCL0=nan CPU=-0.251465) ADD(type=q8_0,n=256,m=16,r=4): FAIL
[GET_ROWS] ERR = 1.000000865 > 0.000000100 ADD(type=q4_0,n=256,m=16,r=4): FAIL