sycl: fix UE4M3 parsing

[clee]

Overview

The NVFP4 quantization format stores a scaling factor for every group of 16 weights, packed into a single UE4M3 byte.

The SYCL GPU code was converting these scale values using the E4M3 path, but that's signed, and these are unsigned values. (The CPU backend converts these values correctly; this bug is in the SYCL backend alone.)

Additional information

The unsloth/Qwen3.6-27B-NVFP4 quant, after converting to GGUF, generates coherent output on my B70 instead of gibberish once this patch is applied.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES

I used GLM-5.2 to diagnose this issue and to generate the patch, but I tested the output manually before and after applying the patch by hand to confirm that the fix works on my Intel Arc Pro B70 GPU.

[arthw]

It's good job!

Thank you!

[mndodd]

Reproduced here.

Opens up an opportunity for further optimizations.

Before:

$ llama-bench --offline -hf CodeFault/Nvidia-Qwen3.6-27B-NVFP4-GGUF:A -p 512,2048 -n 128 -r 3 -ngl 999 -ub 512

model	size	params	backend	ngl	test	t/s
qwen35 27B NVFP4	16.62 GiB	27.32 B	SYCL	999	pp512	664.33 ± 3.81
qwen35 27B NVFP4	16.62 GiB	27.32 B	SYCL	999	pp2048	601.61 ± 57.54
qwen35 27B NVFP4	16.62 GiB	27.32 B	SYCL	999	tg128	4.73 ± 0.32

After (oneDNN Weight Decompression):

$ lama-bench --offline -hf CodeFault/Nvidia-Qwen3.6-27B-NVFP4-GGUF:A -p 512,2048 -n 128 -r 3 -ngl 999 -ub 512

model	size	params	backend	ngl	test	t/s
qwen35 27B NVFP4	16.62 GiB	27.32 B	SYCL	999	pp512	957.21 ± 2.94
qwen35 27B NVFP4	16.62 GiB	27.32 B	SYCL	999	pp2048	896.30 ± 4.25
qwen35 27B NVFP4	16.62 GiB	27.32 B	SYCL	999	tg128	9.40 ± 0.02

(preliminary, don't hold me to it.)

[ggerganov]

If there is a problem in this function, it should be first fixed in the CPU implementation and then all backends should follow that. cc @ggml-org/ggml-cuda

[clee]

If there is a problem in this function, it should be first fixed in the CPU implementation and then all backends should follow that. cc @ggml-org/ggml-cuda

I could not reproduce the problem on the CPU-specific backend. I only had the problem with SYCL.

However, in comparing the CPU implementation and my proposed fix, I did uncover one thing: the CPU implementation returns 0.0f for both 0x00 and 0x7F, and I was missing the 0x7F path. Fixed.

[mndodd]

If there is a problem in this function, it should be first fixed in the CPU implementation and then all backends should follow that. cc @ggml-org/ggml-cuda

The CPU implementation matches gguf-py/gguf/quants.py:NVFP4.ue4m3_to_fp32.