antirez / antirez/ds4

ds4_test fails 29 fusion assertions on M4 — fusion whitelists only admit M3/M5 device names

Abierto
#769 0 comentarios 0 reacciones 0 asignados Ver en GitHub
Lenguaje dominante
C
Estrellas
22.3k
Forks
2.1k
Merge medio
1 d 3 h
PR fusionados (30 d)
4

Descripción

On an M4 Max (128 GiB), `make test` with the DS4F 0731 IQ2XXS GGUF fails 29 assertions in ds4_test, in two clusters: `ds4_gpu_matmul_f16_pair_compressor_store_tensor` (ds4_test.c:1098) and the forced `ds4_gpu_flash_kv_stage_f16_tensor` path (ds4_test.c:2728), plus the mismatch-count assertions that follow once the fused output is never written.

Root cause: the newest decode ports gate on `ds4_gpu_ported_m5_decode_feature_enabled()`, whose pre-M5 predicate admits M1–M4, but the older fusion sites still use literal `ds4_gpu_device_name_contains("M3") || ("M5")` whitelists. On M4 those entry points return 0 by design ("not applicable"), and the tests assert they succeed without replicating the device gate. M1/M2 should fail the same way.

It's not only a test problem: the fifteen name-gated fusions never engage on M4, and several are real wins there (numbers in #770).

#770 admits M4 to the fifteen sites; with it the full suite is green on M4 Max and every fused-vs-reference comparison is bit-exact.

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.