Kazeia-engine

Commit Graph

Author	SHA1	Message	Date
Richard Loyer	bdd528ed25	chantier BigVGAN HMX Phase 2b: refactor sched-friendly + limite backend découverte 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>	2026-05-29 14:05:35 +02:00
Richard Loyer	9de6b76838	chantier BigVGAN HMX Phase 0+2a: audit + chaîne load HTP validée PHASE 0 audit (PERF_ANALYSIS.md + cette commit): - BigVGAN = 95% du decoder (3.24s sur 3.36s), confirmé via KZTTS_DECODER_PROFILE=1 - 26 conv1d (63.7 Gops) + 4 conv_transpose_1d (51.6 Gops) + 30 snake (0.4 Gops) - channels par block : 1024->1536->768->384->192->96->1 - T_cur évolution : 124->992->4960->19840->59520 - poids decoder TOUS en F16 déjà (110 MB F16 conv + 215 MB F32 snake α/β) - ggml_conv_1d = im2col + mul_mat en interne, le graphe expose déjà MUL_MAT - ggml-hexagon ql/ggml supporte : MUL_MAT (HMX fp16), UNARY (exp/silu/etc), SOFT_MAX, ROPE, ADD, MUL, NORM, PAD, etc. PAS supporté : IM2COL, CONV_1D, CONV_TRANSPOSE_1D, SIN - opt_hostbuf=1 default -> HTP buffer CPU-mappable via ION - budget RAM HTP session: 2 GB sur 3.5 GB plafond, ~1.5 GB marge PHASE 2a (chaîne load HTP, sans gain HMX): - Refactor decoder.h + gguf_loader.cpp : load_with_backends(path, devs) crée le sched optionnellement (gated KZTTS_DECODER_SCHED). - tts_engine.cpp : KZTTS_DECODER_HTP=1 -> initialise backend HTP + backend CPU (sched), passe les deux à load_with_backends. - Mode KZTTS_DECODER_HTP=1 sans SCHED : poids 325 MB sur HTP, compute CPU pur lit via opt_hostbuf=1. WAV produit correct, ~baseline perf. - Mode SCHED=1 : sched créé mais sched_alloc_graph plante (buffer_id>=0) car les stages utilisent ggml_init(no_alloc=false) + memset, incompatible avec sched. Refactor stages requis pour activer. Snapshots des modifs decoder dans dist/decoder_patches/ (le repo decoder est externe /opt/Kazeia, fichiers untracked). PHASE 2b à faire prochaine session (~1 session): - stage_bigvgan en pattern sched-friendly: * no_alloc=true + ggml_set_input/output * memset zeros -> ggml_pad_ext * precompute_snake host -> ggml_exp + ggml_div in-graph * sched_reset + alloc + tensor_set + compute + tensor_get - Cible: decoder 3.2s -> 0.5-0.8s (×4-6 sur MUL_MAT HMX) - Snake sin reste CPU (fallback sched), borné à 0.4 Gops/115 total Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-29 11:51:08 +02:00

Author

SHA1

Message

Date

Richard Loyer

bdd528ed25

chantier BigVGAN HMX Phase 2b: refactor sched-friendly + limite backend découverte

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>

2026-05-29 14:05:35 +02:00

Richard Loyer

9de6b76838

chantier BigVGAN HMX Phase 0+2a: audit + chaîne load HTP validée

PHASE 0 audit (PERF_ANALYSIS.md + cette commit):
  - BigVGAN = 95% du decoder (3.24s sur 3.36s), confirmé via KZTTS_DECODER_PROFILE=1
  - 26 conv1d (63.7 Gops) + 4 conv_transpose_1d (51.6 Gops) + 30 snake (0.4 Gops)
  - channels par block : 1024->1536->768->384->192->96->1
  - T_cur évolution : 124->992->4960->19840->59520
  - poids decoder TOUS en F16 déjà (110 MB F16 conv + 215 MB F32 snake α/β)
  - ggml_conv_1d = im2col + mul_mat en interne, le graphe expose déjà MUL_MAT
  - ggml-hexagon ql/ggml supporte : MUL_MAT (HMX fp16), UNARY (exp/silu/etc),
    SOFT_MAX, ROPE, ADD, MUL, NORM, PAD, etc.
    PAS supporté : IM2COL, CONV_1D, CONV_TRANSPOSE_1D, SIN
  - opt_hostbuf=1 default -> HTP buffer CPU-mappable via ION
  - budget RAM HTP session: 2 GB sur 3.5 GB plafond, ~1.5 GB marge

PHASE 2a (chaîne load HTP, sans gain HMX):
  - Refactor decoder.h + gguf_loader.cpp : load_with_backends(path, devs)
    crée le sched optionnellement (gated KZTTS_DECODER_SCHED).
  - tts_engine.cpp : KZTTS_DECODER_HTP=1 -> initialise backend HTP +
    backend CPU (sched), passe les deux à load_with_backends.
  - Mode KZTTS_DECODER_HTP=1 sans SCHED : poids 325 MB sur HTP, compute
    CPU pur lit via opt_hostbuf=1. WAV produit correct, ~baseline perf.
  - Mode SCHED=1 : sched créé mais sched_alloc_graph plante (buffer_id>=0)
    car les stages utilisent ggml_init(no_alloc=false) + memset, incompatible
    avec sched. Refactor stages requis pour activer.

Snapshots des modifs decoder dans dist/decoder_patches/ (le repo decoder
est externe /opt/Kazeia, fichiers untracked).

PHASE 2b à faire prochaine session (~1 session):
  - stage_bigvgan en pattern sched-friendly:
    * no_alloc=true + ggml_set_input/output
    * memset zeros -> ggml_pad_ext
    * precompute_snake host -> ggml_exp + ggml_div in-graph
    * sched_reset + alloc + tensor_set + compute + tensor_get
  - Cible: decoder 3.2s -> 0.5-0.8s (×4-6 sur MUL_MAT HMX)
  - Snake sin reste CPU (fallback sched), borné à 0.4 Gops/115 total

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-29 11:51:08 +02:00

2 Commits