Refactor stage_bigvgan en variante stage_bigvgan_sched :
- ggml_init(no_alloc=true) + mem_size réduit 12 GB -> 16 MB
- ggml_set_input/output sur input/output
- causal_conv1d_TC : ggml_pad_ext au lieu de memset zeros + concat
- apply_snake_TC : lookup d.snake_consts pré-calculé (au lieu de host exp() per-frame)
- Pattern sched_reset + alloc_graph + tensor_set + compute + tensor_get
- Switch dans Decoder::forward : sched ? stage_bigvgan_sched : stage_bigvgan
Snake constants pré-calculées au load_with_backends :
- 29 paires (a_eff, inv_b) stockées dans ctx_const + buf_const sur le même
backend que buf_w. exp() host-side une fois au load au lieu de chaque frame.
- buf_const ~0.1 MB sur HTP0 (29 × 2 × C × f32 avec C de 96 à 1536).
Mesure tablette (KZTTS_DECODER_HTP=1 KZTTS_DECODER_SCHED=1 GGML_HEXAGON_USE_HMX=1) :
baseline CPU pur : decoder 3.34s, bigvgan 3.19s
sched HTP path neuf : decoder 3.95s, bigvgan 3.76s -> REGRESSION 18%
Cause : GGML_SCHED_DEBUG=2 révèle que TOUS les MUL_MAT tombent sur CPU.
ggml_hexagon_supported_mul_mat rejette ggml_nrows(src1) > 1024 (commentaire
'no huge batches (for now)'). BigVGAN block 3 résiduels : conv1d k=7 sur
T=59520, im2col_output [672, 59520] -> 59520 rows >> 1024. Tous les
MUL_MAT BigVGAN sont rejetés -> fallback CPU + copies inutiles -> régression.
PHASE 2b STATUT : refactor fait et stable, mais le gain HMX nécessite
soit (a) modifier ggml-hexagon pour gros batches, (b) splitter MUL_MAT
en chunks ≤ 1024, (c) reprendre via étape F (CP HMX) qui n'a pas ce
problème (nrows ≤ 16 par sub-forward).
Snapshots updatés dans dist/decoder_patches/.
Le path activé seulement si KZTTS_DECODER_SCHED=1 (opt-in, désactivé par
défaut). En mode KZTTS_DECODER_HTP=1 sans SCHED : path legacy CPU pur, perf
inchangée vs baseline (poids juste relogés sur HTP buffer via opt_hostbuf=1).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
bdd528ed25