tag:blogger.com,1999:blog-55105120521546243992026-11-11T18:33:53.874+09:00メモやら記録やらSIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.comBlogger899125tag:blogger.com,1999:blog-5510512052154624399.post-2664485882198141482026-11-11T18:33:53.874+09:002026-11-11T18:33:53.874+09:00

stable-diffusion.cppでSYCLを使っているとどうもメモリー管理がうまくいかなくなっていたので、今までSYCL_USE_LEVEL_ZERO_API=0を指定してzero apiを無効化していたのですが、ggmlをv0.29.0ベースにしたところ、無効化しなくても動くようになったみたいです。詳しく調べていませんが、メモリーの解放処理が少しまともになったのかと。ただ、現状でもメモリーが分断された状態のままの様で、stable-diffusion.cppの処理でエラーが出力されるのは変わらず…。ヒープは関係ないはずなのですが、処理を変えてcmakeするたびに、この辺のメモリー確保処理の動きが変わり、出力可能な画像サイズが変わったりします…。イマイチc++の動きが良く分かってないわけですが、まぁとりあえず1024x1024が出力できていればよしとしていますが、メモリーの分断

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-11193773334735201352026-11-03T16:36:40.306+09:002026-11-04T10:09:20.064+09:00

Fire TV Stick 4K Max - 第2世代（2023）を使用したときにやたらと出力ボリュームが小さくとても違和感が…体感で出力される音量は半分程度でした。結局、試しに使った程度で使用を諦めました。色々と調べると、少し前(2020年以降の)の流行りは出力されるボリュームの音量はやや小さくなっている傾向にあるという事を知りました。現状、Fire TV Stick 4K - 第1世代（2018）を主に使用しています。問題となるのはサポートの問題で、搭載されているfire osのバージョンがそのままとなるために、アプリが起動できなくなるという問題が気になります。fire tabletは結構バッサリと切り捨てられているアプリも多く、特にストリーミングサービス系のプレーヤー関しては更新されなくなったものが…abemaです…ｗまぁ古いタブレットで見ているユーザーは切り捨てても利益に影響

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-32615240208996993402026-11-03T00:10:56.943+09:002026-11-03T00:10:56.943+09:00

夏以降の更新によって、内部的にオブジェクト指向化が進み、各モデルに対応するためパイプラインの実装も精力的に拡張が行われています。主に動画対応の様な部分も強いですけど、それ以外に一番恩恵を受ける修正がVAE出力時に一括処理できなければイメージをタイル割して出力する機能ではないでしょうか？試しに過去のプロンプトをベースにして試していますが、当時はvaeの動作を --vae-on-cpu オプションを指定してCPUで実行する必要がありました。SYCLのメモリー消費量は現在でもバカ食いするままなのですが、この機能のおかげでSYCL上でvaeの実行が行いやすくなりました。分割のためのオーバーヘッドはあるものの処理速度の恩恵がとてつもなく大きいので全く問題になりません。ついでに当時実行したままのプロンプトで画像生成を行ったところ、ほぼ、同じものが出力されるのですが、まったく同じ状態の出力にはならない

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-2454420060972691102026-11-02T00:54:09.003+09:002026-11-02T05:12:19.238+09:00

Qwen Image 2.1 turboはプロンプトがそのまま通る感じですが、FLUX 3 Image Kleinは抑止フィルターの影響か、結構無視されることが多いです。今まで、「日本人」と指定すれば日本人っぽい感じの人物が描かれていたのですが、どうもFLUX 3 Image Kleinは確実に無視されている感じが強いです。どこかの紹介記事に日本語の指示プロンプトは先にpupを行って英語のプロンプトに変換するのが必須らしいのですが、それが原因で無視されている可能性も高いです。 そんなpupを使っていないパターンとなりますが、いつものサンプルを…現状、正方形以外の画像が生成できていないのですが… まずはいつもの犬文字から 車輪のような果実の断面のようなマークが勝手に追加されていますが、こんな感じで素直に出力されました。 いつものフィッシュ画像はこんな感じで、リアルな感じで出力されましたが

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-69660443321901400972026-11-01T17:05:14.650+09:002026-11-01T23:40:47.218+09:00

awkについて何も知らない状態なので、どんなことができるのか？どんな書き方なのか？と言ったところから入っていきました。見たのは、とほほさん（https://www.tohoho-web.com/ex/awk.html）のところが基本となりました。最初のころはあまりまとめられてる言語は無かった気がしますが、１０年ほど前に見たときにものすごい広範囲の言語のまとめがあったので驚いた記憶がありますが、今でもいろいろ増えているのかな？すごいですよねｗで、さらにいくつか参考になりそうなものを検索していきました。が、最終的に根本的なロジックを捨てて、シンプルな形にしました。もともと提示された形はbashスクリプト内でawk  'BEGIN {    current_block = ""}/^\[SYCL\] {    if (current_block

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-64643286855350993472026-10-31T18:41:25.518+09:002026-11-01T17:44:31.136+09:00

昨日serverで動かしてデバッグログを出力させたまま、チャットしてたら気づいたら6056252331バイトのファイルが出来上がっていました…ｗとりあえず、集計スクリプトを実行して試したところ…  1439645611634209 ggml_sycl_compute_forward:11627529 ggml_sycl_compute_forward5225900 ggml_sycl_mul_mat:5225900 ggml_sycl_mul_mat3488154 adjustment_local1704095 ggml_sycl_mul:1704095 ggml_sycl_mul1323366 ggml_sycl_rope:1323366 ggml_sycl_rope 962448 ggml_sycl_op_set_rows: 962448

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-72892851558541261272026-10-30T15:57:57.438+09:002026-10-30T16:03:56.749+09:00

toolsの機能自体はあまり積極的に動かさないようなのですが、時間がかかっても構わないからデバッグログの解析をgemma4でやってもらおうとチャット形式で指示してみました。デバッグの出力ログはstable-diffusion.cppのsyclの出力なので非常に大きいです(笑)ざっくり見てもそれなりにどんな機能が動いているのかはわかるのですが、各関数がどの程度動いているのかボリューム感までは把握しづらい面もあり、お試しで試してみることにしました。最初に対象のファイルがデバッグ出力のログであることを明示したうえで、ファンクション名を抜き出してもらおうとしたところ、やはり最初の100行程度でテキストを集計してくれました。ここでgrepサーチを利用する前提で、３パターンほど全体の集計を行うための方法の提示がありました。A. すべてのユニークな関数/処理名とその合計出現回数B. 特定の関数名（例:

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-37221244005627781722026-10-28T19:05:54.349+09:002026-10-28T19:05:54.350+09:00

昨日、llama.cpp serverのtoolsで少し試していましたが、思っている通りに動作してくれないのであきらめてこちらを試してみました(笑)masterブランチの現時点でコミットされている状態でpullしてcmakeでバイナリを作成。必要なモデルファイルをダウンロードして、実行するだけでtext-to-imageの動作は確認できました。量子化は小さめのQ3_Mを最初に選んで…vaeはそのまま、llmはQ8_0の物で試してみました。量子かはQ4ぐらいまでにしておきたいのですが、最近扱っていたモデルはQ2まで落とさないとメモリー的に出力サイズがかなり制限されてしまうため、サイズが小さいものを使っています。正直Q2まで落としてしまうと輪郭も怪しい感じに出力されてしまうので（この辺は量子化による劣化対策でCFG(やシグマ値)を推奨値ではなく、微調整する必要がありそう）Q3モデルを使った

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-70323398993678307612026-10-26T20:28:06.960+09:002026-10-26T20:28:26.039+09:00

ローカル環境でチャットだけで遊びたかっただけで始めた最初のとっかかりはlocalAIでした。良くも悪くも色々と知らない環境を知る上でとても貴重な体験ができました。llama.cppはそんなlocalAIの中で知った（名前だけは見かけた物の現物がどんなものかは知りませんでした）ものの一つです。最初はggmlというライブラリを使用するために必要だと思っていましたが、llama.cppにはいくつかの実装が行われている形になっていて、コマンドラインで単体のLLMを実行するcliとWebUIを実装しているserverというものがある形になっています。そのうちlocalAIではそのserverをベースにgrpcでbackendに実装していました。（極論をいってしまえばlocalAIは全てgrpcベースのbackendを実装したものをlocalAIで動かしているだけ）個人的にはリッチな環境を用意して

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-69415625067204990462026-10-24T23:03:38.143+09:002026-10-24T23:04:30.069+09:00

のんびりとN150で遊んでいるだけなのですが、昨日からようやく最新のソースから（それなりの制限はあるものの）cmakeできるようになりました。制限に関してはoneAPIをアップデートしたことにより（現時点で）WebP / WebMでエラーが出るようになってしまったので、これらのフォーマットの画像や動画ファイルは使用できない。SYCLを使用しているのでint8系が使用できないか、精度を犠牲にして処理速度を上げられない。そもそもggml-sycl以下に対してパッチを当ててないと内蔵のiGPUでは（主にグリフ処理などでSYCLに非同期実行を行うと）ハングアップしてしまう(最新のoneAPIだと修正されている可能性はあるが、未確認)。stable-diffusion.cppのint8系に対応させたggmlにパッチを当ててもsyclではint8系は動作しない。結果として、SYCL用のcmakeを

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-19529762321492267562026-10-23T00:56:36.068+09:002026-10-23T00:56:36.069+09:00

一部機能をOFFにした状態でcmakeは通っていたのですが、さくっと処理の途中でエラーが発生して出力までたどり着かなかった（これが昨日まで）ので、じっくりと関連する部分のソースや、デバッグ出力を追加したりして動作確認をしていました。パッと見 mmap関連だと思っていたものは、ちゃんとoffとなって動作していたのと、処理が行われても無視された形でスルーされていました。なので何度か実行していたのですが、どうもメモリー確保が上手くいっていない様子。実行時にfreeコマンドで空きメモリを確認しながら行いましたが、要求されているメモリ確保は余裕で行えるだけ空いているので何度か確認していましたが、メモリのフラグメンテーションが影響しているのでは？という結論に。そもそもSoC内蔵のiGPU自体、メモリの扱い方が結構何でもありな様で、明確なVRAMとメインメモリーとの差は実行時の処理速度の差はあるものの

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-62244107574055509252026-10-21T20:16:24.759+09:002026-10-21T20:16:24.759+09:00

8/11日以降のバージョンでビルドすると処理の途中でsegment faultが発生して実行できなくなっていました。時間を見つけては処理を追いかけて、いくつかの仮定を設定していろいろな角度から調べていました。一度、gdbを使って見たのですが、デバッガがまともに動いているのかどうかも良く分からないので放置していましたが、改めて実行してみたところ以下の通り。 Thread 1 "sd-cli" received signal SIGSEGV, Segmentation fault.0x00007ffff7c57244 in sycl::_V1::detail::DeviceKernelInfo::setCompileTimeInfoIfNeeded(sycl::_V1::detail::compile_time_kernel_info_v1::

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-6304172508084764172026-10-14T22:58:01.229+09:002026-10-14T22:58:01.229+09:00

Segment faultにハマっていて気づいていませんでしたが、今朝スマホで色々見ていてQwen Image 2.1にturboが付いている文字を発見し、慌てて調べてみると4日前ぐらいに公開されたようですね。片手間に使用可能そうな量子化モデルをダウンロードして試してみました。Qwen Image 2.1 turboはQwen Image 2.1をファインチューニングしたものとのことでそれなりに出力が一致してくれるのかな？と期待したのですが…似たような感じにはなるものの、結構出力されるものが違っている印象を受けました。あくまでtext to image部分だけしか試していないので、編集や加工については問題が無いのかもしれません。全体的に出力されたものを見ると汚れているイメージが強いです。肌とか髪の毛とか結構派手にダメージを受けている感じのものが出力されました…。逆にQwen Image

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-11345950421971870152026-10-07T00:12:18.586+09:002026-10-07T00:12:18.586+09:00

散歩ゲームをやめた後から始めたのがダフネです。まぁ暇つぶしにはいいんじゃないかなぁとは思いながら始めると、最初のうちでもけっこなバグもあったり、不具合も多かったりしてます。ソシャゲっぽくするより、そのままパッケージで販売してほしいと思いつつも、バグも治らないようだし、一番気になるのはモンスターの種類が微妙…かな？と感じています。モデリングの手間暇が結構かかってそうなので、そこまで要求するのは酷かもしれないですけど。現状レベル30までで、いまだに最初のストーリーをぐるぐる回ってる感じですが、一番つらいのは描画バグで、戦闘中にフリーズではないものの、４～８フレームぐらいを繰り返すというのがあって、そうなるとアプリを再起動させなければなりません。これが地味に多かったりするので、なんかもう挫折しそう…orz

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-64711909339861387832026-10-06T23:37:29.462+09:002026-10-06T23:37:29.463+09:00

IMEは諸事情から旧バージョンのものを使用していたのですが、気づいたら何やら入力がおかしくなりました。再起動すれば治るのかどうかもわかりませんが、とりあえずIMEのモードを旧バージョンから通常バージョンにすることで逃げました。現象としては、英数字入力のはずなのに、コメントにするためにスラッシュを２つ入力すると、何故か一文字目の入力で全角で入力され、二文字目が半角になるという良く分からない状態に…// ではなくなぜか ／/ となる…ｗ標準のモードだとなんかあった気がするけど、とりあえずこれでしのいでおこう… 

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-1446746082407024992026-10-06T15:23:09.537+09:002026-10-06T15:26:25.542+09:00

最新のstable-diffusion.cppはまだいらないかな？とか思っていたのですが、どうやら2週間ほど前にタイトルのQwen Image 2.1がリリースされていたみたいですね。で、stable-diffusion.cppのリリースを見ると2026/09/20 🚀 stable-diffusion.cpp adds Day-0 support for Qwen-Image-2.1 とのこと。さすがの対応の早さです。が、syclで動かせない気配がプンプンするんだよなぁ…とりあえず、別のディレクトリにgit pullしてbuild-sycl内にそのままビルドして…途中でフリーズするかもしれないけど、今までの実行した履歴メモからいくつか試してみると、[WARN   ] model_manager.cpp:1753 - model manager

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-30464655082822163712026-10-01T00:06:17.427+09:002026-10-01T00:06:17.427+09:00

ブラウザの検索ボックスの文字を消そうとバックスペースキーを押しても無反応なので、またブラウザバグってる…と思い、開きなおしても治らず…メモ帳に入力されてる文字を消そうとしても消せず…ようやくキーが死んでいるのに気づきました(笑)思い当たる節は…なんか水が滴って水飛沫がキーに当たってたかもしれないなぁという感じ。水だけなら乾けば何とか復活してほしいところですが、電源が入っている状態だったしダメかなぁ？今使っているネットブックはメモリ価格が高騰したのと同時に市場から消えちゃってちょうどいい大きさのものが無くなっちゃったんだよなぁ…これを機にタブレットに移行するしかないのかな…それともネットブックは辞めて、デスクトップメインにするのがいいのかな？ノートがないと何もできない気がするんだよなぁ…。 

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-53048780997342417702026-09-21T02:24:52.288+09:002026-09-21T02:24:52.288+09:00

今期はいつも以上に知らない話が多かったのですが、あまり期待せずに見始めてみると、結構絵が普通のアニメの仕上がりに、量産系アニメばかりの中、かなり光っていた作品です。初回から唯一まともに見続けた数少ない作品。今期のアニメはやたら多かったのですが、大半途中からどうでもよくなってしまう中、最後まで楽しめたアニメでした。が…エンディングがやたらと演出があったので、まさか第2クールも？と思って確認したらすでに予定通りの様で(笑)なんとなくいい感じに纏まったと思ったら、あくまでもこれがプロローグなんですね…この物語…ワンクール空いて、来年１月からという事で期待して待ちますかね。  

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-39537295577693478372026-09-20T20:32:14.700+09:002026-09-20T21:44:47.083+09:00

あまり時間が取れなかったので、1ヵ月程度sycl関連のソースで遊んでいませんでした。その間も、llama.cppにはggml-syclに対してパッチを行ってビルドしていましたが、stable-diffusion.cppは完全放置していました。手元のソースを確認すると、8/11から触っていない感じでしたが、どうもこの直後にggmlを拡張してint8をベースにした量子化フォーマットに対応するために色々とテコ入れを行っているようで、素のggmlではビルドできない状態になっているようです。ディスカッションにも記録が残っていて、8/12に[Bug] Build Failure: INT8 ConvRot code on master uses undeclared ggml functions #1870という書き込みが行われていました。リリースを見てみると、master-817-bcc7e29

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-46086234338499514132026-08-25T20:15:11.270+09:002026-08-25T20:15:11.270+09:00

4日前からリリースがvX.Y.Z形式のバージョンが振られるようになりました。ggml自体は同期タイミングでバージョンを振り続けていますが、llama.cppはコミットのタイミングでbXXXXX形式のタグで五月雨式にリリースされていた形から変わったので、電車の中でv0.2.0と見かけたときは少し驚きました。が、今日も先ほどv0.3.0とすでにマイナーバージョンが加算されているので本腰を入れて整備する気配です。 

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-67699209995967631312026-08-19T15:53:37.937+09:002026-08-19T15:53:37.937+09:00

タイトル詐欺臭い部分も多い設定ですが、作画やデザインはともかくそこそこテンポよく進むのでかなり楽しみながら見てたりします。結構暴れまわる立ち回りでどうなっちゃうんだろう？と不安が募るわけなんですが、７話目でとりあえず別の場所に移動しちゃったみたいですね。元の国からも過去の仕事の絡みで場所が割れてしまっている状況だったのでそれだけが移動のトリガーだと思っていましたが、思っていた以上に周りにばれている状況だったようで…話的には今回が最終回でもおかしくないような終わり方でしたが、次回はどんな感じになるんでしょうかね(笑) 

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-9251900422668721462026-08-17T04:24:32.863+09:002026-08-17T04:25:19.048+09:00

最初に知ったのはYouTubuのガジェット紹介系で一言あったのがきっかけで始めました。いろんな意味で端末負荷が高いので何度かアンインストールしたり、中断したりしてたりします。数年前ぐらいからとりあえず目標にしたのは365日連続でのポータルハックのメダル目指して頑張ってました。それをなんとか乗り越え、次の目標をレベル１６を目指して頑張ってましたが、ようやく今日、１６になりました。ゲーム的には何度も繰り返せるのですが、まぁ終わりがないし、そこまでガチる気にはなれないし(笑)当初から旅行が趣味か毎日の散歩が日課になっている人向け。まぁぶっちゃけ世捨て人ぐらいしかガチれない感じが強かったわけですが、最後までそのイメージのままでしたね(笑)位置偽装っぽい人も結構多かったり、複数台でやってる感じの人も多く感じました。この辺のチート案件はまぁMMOゲームなのでそういうもんかなと思いますが、この辺の感じ

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-41218378498643438002026-08-13T14:27:15.413+09:002026-08-13T14:27:15.413+09:00

stable-diffusion.cppでパッチを当てていたものをllama.cpp側に当てた形にしておきました。stable-diffusion.cppでは簡単にハングアップしますが、llama.cppの場合、少し使っている程度ではハングアップすることはあまりありませんが、それでもだらだらとチャットしたりしてるとハングアップします(笑)動作速度はどうなんでしょうかね…ただ、GPUですべて処理させた場合のレスポンスは改善してる感じがするのと、CPU側の処理が素の状態と比べると使用率の低下と消費電力の低下は確認できたので、それなりに効果はある気がします。-nglや-tを指定せずに動かすとそれなりに動いてしまうので単純比較は中身が分かっていないとパッと見判断が難しいですね。https://github.com/siriuth/llama.cpp/releases/tag/

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-32341244065120264622026-08-11T17:33:03.904+09:002026-08-11T23:29:28.938+09:00

実行速度以外は安定していたggml-syclで、思っている以上に実行速度が改善しなくなったので若干熱が冷めてきた感じです(笑)ですが、パッチ状態のggml-syclでエディットモードで元の絵を2枚にして実行していたところハングアップすることがありました。本腰を入れる前に小手先でやれることをやってみたのですが、どうも回避できないので、最新化した状態から復習がてら地道にパッチあてていこうかなと。現状ggml v0.16.0ベースで行っていますが、現行ではv0.19.0になっていて、llama.cppベースの物は依然とビシバシ更新されています。sycl部分もそれなりに追加対応が行われていています。ただ、safetensorsを扱っているだけなのを考えると、そこまで細分化して実装しているのは意味があるのかどうか疑問な実装が多々あったり…。で、ついでなのでv0.19.0の素のggml-syclで

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0tag:blogger.com,1999:blog-5510512052154624399.post-38635515926479820082026-08-10T20:48:43.864+09:002026-08-10T20:48:43.864+09:00

無自覚聖女 第3話の16分辺りで派閥抗争の説明で使われていた画像でちらっとどこかで見たような文字っぽいものが…画像の一部ですが、Ovis Imageで出力された文字に似ている気がします(笑)画面全体がこの文字のようなプラカード？で埋め尽くされていたのでインパクトがすごかった… 

SIRIUTHhttp://www.blogger.com/profile/05037080002878195517noreply@blogger.com0