change: `Onnxruntime`型を追加し、そこから`dlopen`/`LoadLibrary*`を行う #802

qryxip · 2024-06-25T16:36:21Z

内容

パブリックAPIにOnnxruntime型を追加し、そこからlibonnxruntimeのdlopen/LoadLibrary*をするようにします。

`Onnxruntime`型

Synthesizerのコンストラクトはこのようになります。

ort = Onnxruntime.load_once()
ojt = OpenJtalk("./open_jtalk_dic_utf_8-1.11")
synth = Synthesizer(ort, ojt)

オプションとしてDLLの"filename"を指定することもできます。

ort = Onnxruntime.load_once(filename="./path/to/onnxruntime.dll")

あと、supported_deviceはOnnxruntimeのメソッドになりました。

supported_devices = ort.supported_devices()

iOSのXCFramework

Rust APIとC APIだけ、dlopen/LoadLibrary*ではなくロード時動的リンクで動く形でビルドできるようにしています。

C APIだと、GHAでのパッケージング時に次のどちらかのコメントアウトをsedで外すようにします。

//#define VOICEVOX_ONNXRUNTIME_LIBLOADING
//#define VOICEVOX_ONNXRUNTIME_LINK_DYLIB

#if !(defined(VOICEVOX_ONNXRUNTIME_LIBLOADING) || defined(VOICEVOX_ONNXRUNTIME_LINK_DYLIB))
#error "either `VOICEVOX_ONNXRUNTIME_LIBLOADING` or `VOICEVOX_ONNXRUNTIME_LINK_DYLIB` must be enabled"
#endif

#if defined(VOICEVOX_ONNXRUNTIME_LIBLOADING) && defined(VOICEVOX_ONNXRUNTIME_LINK_DYLIB)
#error "`VOICEVOX_ONNXRUNTIME_LIBLOADING` or `VOICEVOX_ONNXRUNTIME_LINK_DYLIB` cannot be enabled at the same time"
#endif

VOICEVOX_ONNXRUNTIME_LIBLOADINGの場合、dlopen/LoadLibrary*でlibonnxruntimeをロードします。
VOICEVOX_ONNXRUNTIME_LINK_DYLIBの場合、libonnxruntimeをロード時動的リンクします。load_onceはinit_onceとなり、filenameのオプションが消失します。

iOSのXCFrameworkのみVOICEVOX_ONNXRUNTIME_LINK_DYLIBで、他はVOICEVOX_ONNXRUNTIME_LIBLOADINGです。

libonnxruntimeとlibvoicevox_onnxruntime

Onnxruntime.LIB_NAME = "onnxruntime"としていますが、VOICEVOX/voicevox_project#24以降はこれを"voicevox_onnxruntime"にする方向で考えています。考えているのは大体次の通りです。

libonnxruntimeも普通に読めるようにした上で、リポジトリ上のテストでは引き続きlibonnxruntimeを使う
VOICEVOX_ONNXRUNTIME_LINK_DYLIBの場合リンク対象をlibonnxruntimeのままにする。変えたければpatchelfかinstall_name_toolでバイナリを変更するという形 (実際、今のCOREのXCFrameworkをビルドするにあたってはinstall_name_toolが使われています)
voicevox-ortはlibvoicevox_onnxruntimeのダウンロードを行わない。ユーザーはダウンローダーでlibvoicevox_onnxruntimeをダウンロードする

その他

Cargo.toml

qryxip · 2024-06-25T16:52:07Z

まだドキュメントやテストが詰めきれていませんが、とりあえずこのパブリックAPIがUX的にどうなのかご意見を頂けたらなと思っています。

qryxip · 2024-06-27T18:41:06Z

onnxruntime-libloadingとonnxruntime-link-dylibですが、実行時挙動はどうにもならないとして、APIの形だけでも一つにまとまらないかと考えてみました。macOSのXCFrameworkや、Swift API作成のことを考えるとAPIの形が分かれているのが気になった次第です。

以下のようにすれば、onnxruntime-link-dylibはonnxruntime-libloadingから単にできることを減らしたものになるはずなので、ドキュメントをちゃんと書けばユーザーを驚かせずにすむのではないかと思いました。
(着想を得たのはPythonのctypesです。どういう理由で用意されているかはわかりませんが、Unix限定でctypes.CDLL(None)というのができます)

class Onnxruntime:
    LIB_VERSIONED_FILENAME: str

    # Python APIやJava APIにおいては`filename=None`は実際には許可しない
    def init_once(filename: str | None = LIB_VERSIONED_FILENAME) -> Self:
        ...

Windows, libloading, filename=Some("…"): LoadLibraryExW(_, filename, _)
Windows, libloading, filename=None: 「Windowsでは無理」というエラー
Windows, link-dylib, filename=Some("…"): GetModuleHandleExW(_, filename, _)を開き、そこからのOrtGetApiBase()の戻り値がロード時動的リンクされている方のものと一致しているか検査。違っていたらエラー。検査後はロード時動的リンクされているAPI達を使っていく
Windows, link-dylib, filename=None: 「Windowsでは無理」というエラー
Unix, libloading, filename=Some("…"): dlopen(filename, _)
Unix, libloading, filename=None: dlopen(NULL, _)
Unix, link-dylib, filename=Some("…"): 「dlopenは禁止されている」というエラー
Unix, link-dylib, filename=None: dlopenはせずにリンクされたONNX Runtimeの関数を利用する (dlopen(NULL, _)の方も似た挙動になるはず)

Hiroshiba · 2024-06-27T23:24:37Z

@qryxip とりあえず最後のコメントへのコメントです！

ctypes.CDLLのような形、面白いですね。UXとしてありな気がしました！

Windows, link-dylib, filename=None: 「Windowsでは無理」というエラー

このときって「ロード時動的リンクされている方のもの」は使えない感じですかね？
たぶん今のコアがこの形（ビルド時リンク）だと思ってて、だとしたらできるんじゃないかなと思った次第です。
というのも、たぶんエンジンもこの形になるので、雑にNULLでいけるなら楽そうだな〜と。

他は僕の知識量からコメントできることはなさそうでした！！
UX的には結構便利そうに感じます。

追記：あ、この辺りはそもそもWindowsで２種類作るのかによりそう。
１種のがよければエンジン側が頑張って合わせるのが良さそう。

あ。仮称かもなのですが、libloadingやlink-dylibの名称がややこしめなのがちょっと気になりました！
たぶんdylibは避けて、役目で分けちゃうのがわかりやすいかなと。
で、「iOSのdylibはこれ使うと良いよ」みたいな案内がある感じとか。

名称･･･この辺りのリンク方法？、なんて呼ぶんですかね。。。
libloadingは実行時の読み込みだから、dynamic-loadとか･･･？
link-dylibはビルド時のリンクだから、buildtime-linkとか･･･？
うーん。。。

２値だから１つにまとめてtrue/falseで制御するとかもありかも。
だとしたらlinkする（link-dylib）かしない（libloading）かだから、onnxruntime-linkでtrueとfalseとか･････？

Hiroshiba

一通り全部眺めました！！良さそう！！！

サンプル見た感じとてもわかりやすいですね！！
特にPythonとかの。

C APIのサンプルは、たぶん一方のしかないからわかりやすいんだろなーと思いました。
ビルド時リンクか動的読み込みかにかかわらず、同じ関数を使えるようになれば、実際に使うときも混乱を減らせる気がします･･･！！

いや〜〜〜楽しみですね！！！！！

example/kotlin/README.md

docs/usage.md

.github/workflows/build_and_deploy.yml

qryxip · 2024-06-28T09:07:52Z

Windows, link-dylib, filename=None: 「Windowsでは無理」というエラー

このときって「ロード時動的リンクされている方のもの」は使えない感じですかね？たぶん今のコアがこの形（ビルド時リンク）だと思ってて、だとしたらできるんじゃないかなと思った次第です。

SymInitialize(W)を使ってよいのなら「externなONNX RuntimeのAPIに対する実体を持っているonnxruntime.dll」を見つけだすことができるのですが、ちょっとこれを使うのには抵抗を覚えました。

というのも、たぶんエンジンもこの形になるので、雑にNULLでいけるなら楽そうだな〜と。

追記：あ、この辺りはそもそもWindowsで２種類作るのかによりそう。１種のがよければエンジン側が頑張って合わせるのが良さそう。

単に"onnxruntime.dll"とだけ指定すれば前もってctypes.CDLLで開いた方のonnxruntime.dllを開いてくれるので、compatible_engineだとそれでいいのではと思います。voicevox_onnxruntime.dllでも同様 (確かめました)。

あ。仮称かもなのですが、libloadingやlink-dylibの名称がややこしめなのがちょっと気になりました！たぶんdylibは避けて、役目で分けちゃうのがわかりやすいかなと。で、「iOSのdylibはこれ使うと良いよ」みたいな案内がある感じとか。

２値だから１つにまとめてtrue/falseで制御するとかもありかも。だとしたらlinkする（link-dylib）かしない（libloading）かだから、onnxruntime-linkでtrueとfalseとか･････？

RustのfeatureはAPIの拡張を行うもので「デフォルトの挙動」を変えるべきではないとされているので、それでやるとしたらonnxruntime-link | onnxruntime-no-linkの二択で両方選択したらコンパイルエラーという形ですね。
(といってもfeatureでデフォルトの挙動を変えるクレートは世に溢れていて、ortもその一つだったりするのですが…)

名称･･･この辺りのリンク方法？、なんて呼ぶんですかね。。。 libloadingは実行時の読み込みだから、dynamic-loadとか･･･？ link-dylibはビルド時のリンクだから、buildtime-linkとか･･･？うーん。。。

「静的リンク」, 「ロード時動的リンク」, 「実行時動的リンク」の三つのどれかなのか混乱しないような名前ですかね…
(pykeio/ortはONNX Runtimeの静的リンクをやっているライブラリだったりするし)

Hiroshiba · 2024-06-28T09:36:56Z

SymInitialize(W)を使ってよいのなら「externなONNX RuntimeのAPIに対する実体を持っているonnxruntime.dll」を見つけだすことができるのですが、ちょっとこれを使うのには抵抗を覚えました。
単に"onnxruntime.dll"とだけ指定すれば前もってctypes.CDLLで開いた方のonnxruntime.dllを開いてくれるので、compatible_engineだとそれでいいのではと思います。voicevox_onnxruntime.dllでも同様 (確かめました)。

よくわかってないのですが、エンジン側はたしかに名前指定で良さそうに思いました！
よくよく考えれば今そんな感じになってました。ファイル名で検索して見つかったらそれ指定、みたいな感じだった記憶。

となると、掲げられた2^3パターンの挙動で良さそう感！！

RustのfeatureはAPIの拡張を行うもので「デフォルトの挙動」を変えるべきではないとされているので

おおーなるほどです。それはそうかも。
となると、片方をデフォルトにし、もう片方はプラスにするみたいなのもありかも？
今のmainブランチの実装（ビルド時にリンクする）をデフォルトとするならonnxruntime-no-linkだけ、ビルド時リンクしないのをデフォルトにするならonnxruntime-linkで良さそう。link-on-buildとかでも良いかもしれない。

「静的リンク」, 「ロード時動的リンク」, 「実行時動的リンク」の三つのどれかなのか混乱しないような名前ですかね…

link-on-buildとlink-on-runtimeとかで良い気もしてきました。
まあ最悪注釈コメントかドキュメントがあれば別に良いかも。

qryxip · 2024-06-28T16:48:42Z

onnxruntime-loadとonnxruntime-link-cdylibでどうでしょうか?
「ロード時動的リンク」(run-time dynamic linking)ってあまり言わない気がしますし、"link"で通じそうな気がします。
(といっても正確に区別するときにロード時動的リンクと言ったりはするのですが)

追記: 静的リンクをやる予定が一切無いならonnxruntime-linkでもいいかも?

Hiroshiba · 2024-06-28T17:10:49Z

onnxruntime-loadとonnxruntime-link-cdylibでどうでしょうか?
「ロード時動的リンク」(run-time dynamic linking)ってあまり言わない気がしますし、"link"で通じそうな気がします。

良さそう！！
onnxruntime-linkも良さそう。他にはonnxruntime-load-cdylibも良さそう！
どれもややこしさは解消されてると感じます！！

qryxip · 2024-06-29T15:07:34Z

b1dca9c (#802)
f0c720c (#802)
4af36e0 (#802)
249f8f3 (#802)
7b57268 (#802)
e8dc442 (#802)
フィーチャ名はload-onnxruntimeとlink-onnxruntimeにしてみました。

…ちょっと"load"と"link"で目が滑りそう。load-ortとlink-ortにしたらましになるかも?
(実際今CIが落ちまくったのは、私が"load"と"link"を二箇所で間違えたためです)

qryxip · 2024-06-29T17:20:17Z

#802 (comment)
放送でも話したのですが、やはりどうあがいても二つは別々の挙動ですし、Swift APIも多分XCFramework経由でONNX Runtimeを読むことになりそう(i.e. "load"ではなく"link"で固定)なのでこのアイデアは取り止める方向にしようと思います。

qryxip · 2024-06-29T18:41:37Z

c18e335 (#802): build_and_deployでsedをし損ねていたので直しました。
1492995 (#802): ドキュメントの表記のずれとかを直しました。
e619d8b (#802): C APIにOnnxruntime::LIB_{,UN}VERSIONED_FILENAMEのgetterを追加しました。

qryxip · 2024-06-30T17:33:35Z

c79c3f2 (#802)
init_onceとload_onceの片方のみが利用であることがC APIのドキュメントからわからないので、"Availability"というセクションを追加してみました。

Hiroshiba · 2024-06-30T20:42:58Z

バイナリのリリースではiOSだけlinkで、他は全部loadでいいと思います (今のPRの状態がそうなっています)。

こちらは賛成です！

あと気づいたのですが、C 言語・Rust以外もlink/load片方だけ提供で良さそうなことに気づきました！
なのでCとRustのドキュメントがOK なら良さそう！

Availability

良さそう！　だけど結構見ない人多そう･･･！　それでもここに案内があればそれで良さそう！

UX に関して色々考えてみました！
結論から言うと、関数は分けていいと思います！！

先ほどの通り、CとRust以外のドキュメントはそもそもlink/load片方しか出ないので無視できるはず。
あとはCとRustでどう調理するかかなと！

RustとC言語APIは、結構プログラミングを知ってる人を想定して良いと思います。
なので、結構プログラミングが分かってる人に伝わるドキュメントが書けるならOK。

Rustユーザーは相当分かっていると思うので、link/loadをそのまま説明してもOK。
link用とload用の関数が分かれているのもOK。多分むしろ別れていた方が良い。

Cユーザーはわりとライト層だと思うので、link/loadをそのまま説明するのは避けた方が良さそう。
代わりに「iOSかどうか」で説明を分けるのなら伝わりそう。この説明だったら別れてても良いはず。

Rust向けドキュメントは置いといて、C向けドキュメントは各関数ごとに「iOSでしか使えないか、iOS以外でしか使えないか」が案内されてれば良さそう！
一応ちゃんとわかってる人向けに、リンクなのかロードなのかみたいな説明もあっても良さそう。

Cユーザー向けのVOICEVOXコアの使い方がいろんな記事で紹介され始めたらもっと簡略化しても良さそう。
それまではちょっとメンテナンスめんどくさいけど丁寧かつ初学者にもちょっと分かりやすい説明の方が良さそう

Rust向けドキュメントは･･･お任せします！！
多分 @qryxip さんが分かりやすい形が一番わかりやすい！

VOICEVOX#802 (comment)

qryxip · 2024-07-01T17:59:57Z

dc587ae (#802): C APIでの紹介を「iOSか否か」にしてみました。またRust APIのCargo feature部分に書いていたコメントを、Rust APIのrustdocに移した上で説明も詳細化しました。
e99b293 (#802): C APIのビルドについて書いてあるドキュメントにヘッダの書き換えについて書いてなかったので、付け加えました。

qryxip · 2024-07-02T05:52:02Z

c545f89 (#802)
f60cd0e (#802)
このPRの主旨から若干外れますが、cargo test -p voicevox_core --features {load,link}-onnxruntime (非--workspace)がdoctestを含めて通るようにしました。
~~(このPRで織り込んだdoctest用の工夫が今後壊れるかもしれないため)~~
追記: CIはそのままにしました。非--workspaceビルドでのテストはそんなに重要じゃないので。

Hiroshiba

LGTM！！

ドキュメントはもしかしたらリリースまでに変更させていただくかもですが、とりあえずマージして進めるのは問題なさそう！！
楽しみですね！！

もしかしたらまだ何か残ってるかもなのでマージせず置いています。
問題なければマージしていただければ！！

.github/workflows/generate_document.yml

qryxip · 2024-07-02T09:04:25Z

https://github.com/qryxip/voicevox_core/actions/runs/9757413271
https://github.com/qryxip/voicevox_core/actions/runs/9757419045
- download_testが落ちてるのは、残りのターゲットをビルドする onnxruntime-builder#26でDirectMLとCUDAを一緒くたにしてしまったため (microsoft/onnxruntimeでは"-gpu"と"-cuda12"で分けている)。なんか故意にやったような記憶があるような無いような気がするけど、CUDA版も結構大きいし普通に分けた方がいいかも…?

Hiroshiba · 2024-07-03T12:54:17Z

ちょんと把握できてないのですが、とりあえず問題なければ（mainにマージすればテストは通るとか、リリースを一度すれば通るとか）マージしても大丈夫かなと！

qryxip · 2024-07-03T13:01:33Z

問題はある（ダウンローダーで--device directmlを指定するとonnxruntime_providers_cuda.dllまで付いてくるし、リリースはできてもdownload_testは落ちる）のですが、onnxruntime-rsからortに切り替えた時点でこの問題は発生しており、このPRに起因はしていないと思います。

qryxip · 2024-07-03T13:22:30Z

#804

Hiroshiba · 2024-07-03T17:22:21Z

すいませんちょっとわかっておらず。。。 🙇
あ！　ortに切り替える時点でdownload_testは落ちるはずだったんだけど、download_testの稼働条件にcargo.tomlの更新が含まれいなくてテストが回ってなく、このプルリクエストで初めてテストが回った、みたいな感じでしょうか？

ま～だとしたらこのプルリクエストはマージしちゃってもいいのかなと思いました！！
ただmainブランチのテストが落ちちゃうことにはなる？ので、気になるようでしたら先にそっちを修正でもいいかなと。

どちらでも！！別にいいならマージしていただければ！
（個人的にはどっちにしろ一長一短ですが、このプルリクエストは大きいのでとりあえずマージが進めやすいのかなと思いました。）

qryxip · 2024-07-03T23:23:51Z

mainブランチのテストが落ちちゃうことにはなる？ので

このリポジトリでdownload_testが最後に動いたのは5ヶ月前ですね。
https://github.com/VOICEVOX/voicevox_core/actions/workflows/download_test.yml

download_testの稼働条件にcargo.tomlの更新が含まれいなくてテストが回ってなく、このプルリクエストで初めてテストが回った、みたいな感じでしょうか？

こんな感じです…

voicevox_core/.github/workflows/download_test.yml

Lines 10 to 19 in d3b559c

    
           # 新しいビルドができるまで、このworkflowが壊れて動かないことを許容する 
        
           # https://github.com/VOICEVOX/voicevox_core/issues/741#issuecomment-1935303742 
        
           #push: 
        
           #  branches: 
        
           #    - main 
        
           #pull_request: 
        
           #  paths: 
        
           #    - "Cargo.*" 
        
           #    - "crates/downloader/**" 
        
           #    - ".github/workflows/download_test.yml"

私が貼ったGHAのログは、qryxip/voicevox_coreで「バージョン999.999.999のリリース」を行うことによってdownload_testを作動させたものです。

Hiroshiba · 2024-07-04T07:49:13Z

あーーーーーーなるほどです！！！
このPRのテストが落ちていたのが、download_test由来だと勘違いしてました！！！
そうか、テスト落ちるよねってことでそういえば停止してましたね。。。

追加コミットも見ました、コード的にはOKなのでマージしてOKならしていただければ！！
（完了のタイミングがわからない）

qryxip · 2024-07-05T00:04:27Z

@takejohn 共有です!

Onnxruntimeが追加され、Synthesizerのコンストラクタに要求されるようになりました。
- Python APIとJava APIでは、ラッパー言語側で「シングルトンインスタンス」を持つようにしています。
supported_devicesはOnnxruntimeのメソッドになりました。
SynthesizerはOnnxruntimeのgetterを持つようになります。
featureとしてload-onnxruntimeとlink-onnxruntimeが追加されました。ただしPythonとJavaではload-onnxruntimeで固定です。Node.jsもそうすることになると思います。

change: Onnxruntime型を追加し、そこからdlopen/LoadLibrary*を行う

501dc4c

qryxip mentioned this pull request Jun 25, 2024

add: VOICEVOX CORE用の初期化経路を構築する VOICEVOX/ort#6

Merged

qryxip commented Jun 25, 2024

View reviewed changes

Cargo.toml Show resolved Hide resolved

Hiroshiba reviewed Jun 27, 2024

View reviewed changes

example/kotlin/README.md Show resolved Hide resolved

docs/usage.md Outdated Show resolved Hide resolved

Hiroshiba reviewed Jun 28, 2024

View reviewed changes

.github/workflows/build_and_deploy.yml Outdated Show resolved Hide resolved

qryxip added 3 commits June 28, 2024 23:08

KotlinのexampleにFIXMEを追加

0979c20

"ONNX Runtimeを表す" → "AIエンジンの"

ba81393

ドキュメントとコメントを追加

379cc44

qryxip marked this pull request as draft June 29, 2024 12:59

qryxip added 2 commits June 29, 2024 23:31

フィーチャをリネーム

b1dca9c

fixup! フィーチャをリネーム

f0c720c

qryxip added 5 commits June 30, 2024 00:17

fixup! フィーチャをリネーム

4af36e0

fixup! フィーチャをリネーム

249f8f3

fixup! フィーチャをリネーム

7b57268

fixup! フィーチャをリネーム

e8dc442

voicevox-ortを更新

9cfc7b1

qryxip added 3 commits June 30, 2024 02:26

sedのし損ねを修正

c18e335

ドキュメントやコメントを更新

1492995

C APIに定数のgetterを追加

e619d8b

voicevox-ortを更新

29eb302

C APIのドキュメントに"Availability"のセクションを追加

c79c3f2

qryxip added 2 commits July 2, 2024 02:55

フィーチャに関するドキュメントを更新

dc587ae

VOICEVOX#802 (comment)

C APIのビルドに関するドキュメントのヘッダファイル周りを更新

e99b293

voicevox-ortを更新

cc1f6ff

qryxip marked this pull request as ready for review July 1, 2024 19:34

qryxip added 4 commits July 2, 2024 14:21

JavaStrをCStr::to_strしない

c301b11

fixup! JavaStrをCStr::to_strしない

8a1e2d1

不要な依存を削除

07d70e0

link-onnxruntimeでcargo testが通るようにする

c545f89

fixup! link-onnxruntimeでcargo testが通るようにする

f60cd0e

Hiroshiba approved these changes Jul 2, 2024

View reviewed changes

.github/workflows/generate_document.yml Show resolved Hide resolved

qryxip mentioned this pull request Jul 3, 2024

Windows向けONNX RuntimeのビルドでDirectMLとCUDAが一緒くたになっている #804

Open

3 tasks

fixup! link-onnxruntimeでcargo testが通るようにする

c8c7813

qryxip merged commit 537d9b2 into VOICEVOX:main Jul 4, 2024
38 checks passed

This was referenced Jul 7, 2024

Node.js向けのFFIを実装 #758

Open

chore: tool.maturin.skip-auditwheel = false #806

Merged

gh actionsで追加およびmanylinuxでビルドできるように変更 #693

Open

qryxip linked an issue Sep 5, 2024 that may be closed by this pull request

Windowsデフォルトのonnxruntimeが使われた時に気付けるようにしたい #644

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

change: `Onnxruntime`型を追加し、そこから`dlopen`/`LoadLibrary*`を行う #802

change: `Onnxruntime`型を追加し、そこから`dlopen`/`LoadLibrary*`を行う #802

qryxip commented Jun 25, 2024 •

edited

Loading

qryxip commented Jun 25, 2024

qryxip commented Jun 27, 2024 •

edited

Loading

Hiroshiba commented Jun 27, 2024 •

edited

Loading

Hiroshiba left a comment •

edited

Loading

qryxip commented Jun 28, 2024

Hiroshiba commented Jun 28, 2024

qryxip commented Jun 28, 2024 •

edited

Loading

Hiroshiba commented Jun 28, 2024

qryxip commented Jun 29, 2024 •

edited

Loading

qryxip commented Jun 29, 2024 •

edited

Loading

qryxip commented Jun 29, 2024

qryxip commented Jun 30, 2024 •

edited

Loading

Hiroshiba commented Jun 30, 2024 •

edited

Loading

qryxip commented Jul 1, 2024

qryxip commented Jul 2, 2024 •

edited

Loading

Hiroshiba left a comment

qryxip commented Jul 2, 2024

Hiroshiba commented Jul 3, 2024

qryxip commented Jul 3, 2024

qryxip commented Jul 3, 2024

Hiroshiba commented Jul 3, 2024

qryxip commented Jul 3, 2024 •

edited

Loading

Hiroshiba commented Jul 4, 2024 •

edited

Loading

qryxip commented Jul 5, 2024

change: Onnxruntime型を追加し、そこからdlopen/LoadLibrary*を行う #802

change: Onnxruntime型を追加し、そこからdlopen/LoadLibrary*を行う #802

Conversation

qryxip commented Jun 25, 2024 • edited Loading

内容

Onnxruntime型

iOSのXCFramework

libonnxruntimeとlibvoicevox_onnxruntime

関連 Issue

その他

qryxip commented Jun 25, 2024

qryxip commented Jun 27, 2024 • edited Loading

Hiroshiba commented Jun 27, 2024 • edited Loading

Hiroshiba left a comment • edited Loading

Choose a reason for hiding this comment

qryxip commented Jun 28, 2024

Hiroshiba commented Jun 28, 2024

qryxip commented Jun 28, 2024 • edited Loading

Hiroshiba commented Jun 28, 2024

qryxip commented Jun 29, 2024 • edited Loading

qryxip commented Jun 29, 2024 • edited Loading

qryxip commented Jun 29, 2024

qryxip commented Jun 30, 2024 • edited Loading

Hiroshiba commented Jun 30, 2024 • edited Loading

qryxip commented Jul 1, 2024

qryxip commented Jul 2, 2024 • edited Loading

Hiroshiba left a comment

Choose a reason for hiding this comment

qryxip commented Jul 2, 2024

Hiroshiba commented Jul 3, 2024

qryxip commented Jul 3, 2024

qryxip commented Jul 3, 2024

Hiroshiba commented Jul 3, 2024

qryxip commented Jul 3, 2024 • edited Loading

Hiroshiba commented Jul 4, 2024 • edited Loading

qryxip commented Jul 5, 2024

change: `Onnxruntime`型を追加し、そこから`dlopen`/`LoadLibrary*`を行う #802

change: `Onnxruntime`型を追加し、そこから`dlopen`/`LoadLibrary*`を行う #802

qryxip commented Jun 25, 2024 •

edited

Loading

`Onnxruntime`型

qryxip commented Jun 27, 2024 •

edited

Loading

Hiroshiba commented Jun 27, 2024 •

edited

Loading

Hiroshiba left a comment •

edited

Loading

qryxip commented Jun 28, 2024 •

edited

Loading

qryxip commented Jun 29, 2024 •

edited

Loading

qryxip commented Jun 29, 2024 •

edited

Loading

qryxip commented Jun 30, 2024 •

edited

Loading

Hiroshiba commented Jun 30, 2024 •

edited

Loading

qryxip commented Jul 2, 2024 •

edited

Loading

qryxip commented Jul 3, 2024 •

edited

Loading

Hiroshiba commented Jul 4, 2024 •

edited

Loading