Siriuth's Diary: ggml

syclで安定して動いてくれるように気づけば結構書き換え続けていますが、そろそろ大元のggmlとマージしなければ…とおもいつつ書き換えたソースをちゃんと保存したうえでgithub上で整理してみました。イマイチ使い方が分からないのと、クライアント上のgitの使い方も良く分からない感じでやっているので漏れているものもありそうですが、ggml_sycl_patchからpullしてmakeが通ったのですが、気づかないうちにベースとなるstable-diffusion.cppもpullしてしまった感じでmakeの動作が変わったようなので、stable-diffusion.cppもpullして整えてからggmlをggml_sycl_patchへ挿げ替えてmakeを通してみました。

2026年6月13日土曜日

Flux.2 Klein の実行命令

cpy_f32_f32の部分を手を入れて、結構足掻いてみた物の、最終的には現状のロジックのまま、SYCLに対する純粋な最適化を行った形で落ち着きました。

途中経過

七転八倒しながら結構いい感触を得られています。

原因不明のエラーの調査は進めていないので512x512レベル止まりですが、cpyロジックも手を加えた結果、

vae 24.13s 全体では 322.93s（テキストエンコードはCPU）となりました。

手元のテキストの過去の記録を見てみると…vaeのベストと比べると誤差レベルで遅くなっていますが、全体では20s程度短くなっています。

GGML的にはdup（複製）の中のcpyロジックのf16->f32とf32->f16部分のみ。モデルファイルがQ4_K_M、Q8_0、safetensorsファイルを使っているのでこの辺の変換にも手を加えるともっと実行速度が短くなりそうです。

あと、実際のログを見て効果の高そうな処理から手を加えた方が効果的かなとも。

cpyのロジックを見る限り、正当に処理を実装しているのでとても無駄が多い実装になっています。どうしても計算量を減らそうとするとそのままではあまり効果が出ないので、実データをを踏まえて実装しなおしています。そのため、結構限定的な実装になってはいます。

当面の目標としては512x512で1分ぐらいで出来上がると嬉しいかなぁ…とか思いながら遊んでいますが、vaeベースを考えると 24秒×5=120秒程度ぐらいには行けるのかな？とは感じていますが…メモリ的にテキストエンコードがCPUのままにしているのでこれよりは遅くなりそうかな？

そういえばLocalAIのバージョンアップも行われていますね…SYCLが楽しすぎて全然触れていませんが(笑)

2026年5月13日水曜日

sycl:: と dpct:: の違いは何でしょう？ｗ

namespaceが違うというのはわかるので、違っているような感じなのですが、どこかの定義で一致してるのかな？

ggml/sycl内ではcommon.hppでtypedef sycl::queue_ptr *queue_ptrとか記述があったので、sycl内では特にしていなければsycl::queue_ptrとなっているはずなのですが、dpct::queue_ptrと明示されているところもあるわけでして…

syclとdpctの違いも良く分かってないのですが、sycl2020ではsycl::queue_ptrと記述するのがよろしいようで…ただ、dpctのドキュメントではdpct::を使えという指示が明記されているので、正直悩みますｗ

2026年5月11日月曜日

dpct::queue_ptrって？

enum ggml_status ggml_backend_graph_compute(ggml_backend_t backend, struct ggml_cgraph * cgraph) {
enum ggml_status err = ggml_backend_graph_compute_async(backend, cgraph);
ggml_backend_synchronize(backend);
return err;
}

結局のところ、いろいろ経由したものの長い旅を経て、ようやくここまでたどり着いた…ｗ