Question 1

Jasna のエラー「LTX worker could not start: Windows reports a different program path for the Jasna window」を修正する方法

Accepted Answer

このエラーは、Windows が Jasna の古いプログラムパスを保持している場合に発生します。一般的には、Jasna フォルダーの名前変更や移動を行った後、あるいは以前に古いバージョン（例：v0.10.0）を実行していた状態で再起動せずに、別のフォルダーから新しいバージョン（例：v0.11.2）を起動した場合に発生します。解決方法：1) Windows を再起動してから Jasna を再度実行してください。ほとんどの場合、これで解決します。2) 通常のローカルディスク上の通常のフォルダーから Jasna を実行してください。RAM ドライブ、マップされたネットワークドライブ、subst ドライブ、VeraCrypt ボリューム、またはジャンクションを含むパスは避けてください。3) v0.11.2 以降にアップグレードしてください。開発者は次のリリースでパスチェックを変更し、パス名に依存しなくなりました。

Question 2

MIOpen が畳み込みカーネルを再探索することが原因で発生する、AMD GPU (ROCm/Windows) でのパフォーマンス低下と FPS 低下を修正する方法

Accepted Answer

AMD/Windowsでは、ROCm wheelsにはMIOpenシステムのFind/Perf DBが同梱されておらず、findタイマーが壊れているため、すべての畳み込み形状が出現するたびに再ソルブされます。新しい入力形状が現れるにつれてスループットが低下します(CPUがMIOpenに張り付いている間、GPUはアイドル状態になります)。回避策:モデルをロードする前に、以下の環境変数を設定してください:

```bash
export MIOPEN_FIND_MODE=3          # HYBRID: ヒューリスティック優先、検索結果をユーザーFindDbに永続化
export AMD_COMGR_CACHE=1           # comgrのコンパイル成果物を永続化
export AMD_COMGR_CACHE_DIR=/path/to/persistent/dir
```

Windowsの場合:`set MIOPEN_FIND_MODE=3`(またはシステム環境変数から設定)。初回実行でユーザーFindDb(`%USERPROFILE%\.miopen\db\*.ufdb.txt`)が生成され、2回目以降の実行ではキャッシュされたカーネルが再利用されます。実測の改善効果:エンドツーエンドFPSが+37%、プライマリ復元が4倍高速化(79 ms/f → 20 ms/f)、さらにVRAM使用量も削減(9.0 → 7.1 GB)。`MIOPEN_FIND_ENFORCE`は設定しないでください — 1/2以外の値は拒否され、`2`は壊れたタイマーパスに固定されてしまいます。品質に変化はなく、選択されるカーネルが異なるだけです。jasnaではこれは修正済みです:mainはAMD上で`MIOPEN_FIND_MODE`をデフォルトでHYBRIDに設定するようになり、次のAMDビルドに同梱されます — 更新するだけです。上流の不具合はROCm/TheRock #7958で追跡されています。

Question 3

JASNA LTX worker の ProtectionError 'invalid LTX executable mapping' を修正する方法

Accepted Answer

LTX ワーカーの ProtectionError は、サードパーティ製ソフトウェアがワーカープロセスに DLL を注入することが原因で発生します。最も多いのはアンチウイルスの動作検査(ふるまい検知)によるものです(なお、RTSS や MarkAny は、別問題である起動時の 0xc0000428 ダイアログの原因にしかなりません)。ESET アンチウイルスでの修正方法: 1) ESET を開き、Setup → Advanced setup (F5) に進みます。2) Protections → HIPS → Deep behavioral inspection → Exclusions → Edit に移動します。3) jasna.exe への完全なパスを追加します(例: C:\Users\<user>\Desktop\jasna 0.11.1\jasna.exe)。4) JASNA を再起動し、LTX を再度実行します。別のアンチウイルスを使用している場合は、代わりにその behavioral/HIPS/DeepGuard の除外リストに jasna.exe を追加してください。起動時の DLL エラーダイアログ(RTSSHooks64.dll / IMGSF50Filter_x64.dll、エラー 0xc0000428)も解消するには: RTSS のアプリケーションプロファイルに jasna.exe を追加して 'Application detection level: None' に設定し、MarkAny Image SAFER を停止または除外します。どのプログラムがワーカーに注入しているかを診断するには、エラーを再現しながら、Microsoft Process Monitor でフィルター 'Process Name is jasna.exe' および 'Operation is Load Image' を設定して使用します。

Question 4

Windows ROCm (BasicVSR++ eager パス) で 'no frame encoded' ウォッチドッグエラーにより JASNA パイプラインが停滞する問題を修正する方法

Accepted Answer

環境変数 `JASNA_BV_HIP_GRAPH=1`（デフォルト）を設定すると、BasicVSR++ で eager forward の代わりに HIP グラフリプレイパスが使用されます。このストールは、Windows ROCm ビルド（例: RX 7900 XT、torch 2.14+rocm）で `JASNA_BV_HIP_GRAPH=0`（eager モード）の場合にのみ発生し、検出スレッドが RF-DETR DINOv2 バックボーン内の MIOpen 畳み込みの内部で停止したまま戻らず、エンコードストールのウォッチドッグが繰り返し発火します。グラフリプレイは、同じ入力（1080p および 8K）では確実に完了します。考えられる根本原因は、パイプラインの再構築後に検出器と eager リストアラーが GPU ワークを同時に送信する際に発生する MIOpen の find/compile レースです。`MIOPEN_LOG_LEVEL` や MIOpen の `FIND_MODE` バリアントを使った計測ビルドを実行することで、診断に協力できます。

Question 5

Jasna 0.11.2が長時間の動画のスキャン（ステップ1）中に99%で固まるのはなぜですか？

Accepted Answer

これは v0.11.2 における既知のパフォーマンスバグです。スキャンが99%に達した直後、動画が長いほど処理が大幅に遅くなり、2時間の動画では数分間フリーズしているように見えることがあります。開発者はこれを修正し(テストでは35秒から3.5秒に短縮)、その修正は 0.11.2 の次のリリースに含まれているため、最新バージョンに更新してください。更新後もまだフリーズしているように見える場合は、Log ボタンをクリックして完全なログをエクスポートし、動画の長さと一緒に報告してください。

jasna

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト