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 卷，或包含 junction（联接点）的路径。3) 升级到 v0.11.2 之后的版本：开发者在下一个版本中修改了路径检查逻辑，使其不再依赖路径名称。

Question 2

如何修复由 MIOpen 重新求解卷积核导致的 AMD GPU（ROCm/Windows）性能缓慢和 FPS 衰减问题？

Accepted Answer

在 AMD/Windows 上,ROCm wheels 发布时未附带 MIOpen 系统级 Find/Perf DB,且 find 计时器存在故障,因此每个卷积形状在每次出现时都会被重新求解 —— 随着新输入形状的出现,吞吐量会逐渐下降(GPU 空转,而 CPU 被 MIOpen 占满)。解决方法:在任何模型加载之前设置环境变量:

```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`);从第二次运行开始,缓存的 kernel 会被复用。实测收益:端到端 FPS 提升 37%,primary restoration 速度提升 4 倍(79 ms/f → 20 ms/f),同时 VRAM 占用更低(9.0 → 7.1 GB)。请勿设置 `MIOPEN_FIND_ENFORCE` —— 除 1/2 以外的值会被拒绝,而 `2` 会锁定在损坏的计时器路径上。质量不变;仅所选 kernel 不同。在 jasna 中,此问题已修复:main 分支现在在 AMD 上将 `MIOPEN_FIND_MODE` 默认设为 HYBRID,将随下一个 AMD 构建版本发布 —— 直接更新即可。上游缺陷在 ROCm/TheRock #7958 中跟踪。

Question 3

如何修复 JASNA LTX worker 的 ProtectionError 错误“invalid LTX executable mapping”？

Accepted Answer

LTX worker 的 ProtectionError 是由第三方软件向 worker 进程注入 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。如果你使用的是其他杀毒软件，请将 jasna.exe 添加到其行为检测/HIPS/DeepGuard 排除列表中。若要同时消除启动时的 DLL 错误对话框（RTSSHooks64.dll / IMGSF50Filter_x64.dll，错误代码 0xc0000428）：在 RTSS 应用程序配置文件中添加 jasna.exe，并将 'Application detection level' 设置为 'None'，同时停止或排除 MarkAny Image SAFER。要诊断是哪个程序向 worker 进程注入了 DLL，可在重现错误时使用 Microsoft Process Monitor，并设置过滤器 'Process Name is jasna.exe' 和 'Operation is Load Image'。

Question 4

如何修复 JASNA 流水线在 Windows ROCm 上因 "no frame encoded" 看门狗错误导致停滞的问题(BasicVSR++ eager path)?

Accepted Answer

将环境变量 `JASNA_BV_HIP_GRAPH=1`（默认值）设置为使用 BasicVSR++ 的 HIP 图重放路径，而非 eager 前向执行。卡顿仅在 `JASNA_BV_HIP_GRAPH=0`（eager 模式）的 Windows ROCm 构建版本中出现（例如 RX 7900 XT、torch 2.14+rocm），此时检测器线程停驻在 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 中一个已知的性能 bug：扫描进度达到 99% 后，视频越长，处理速度就越慢——一段 2 小时的视频可能会卡住好几分钟。开发者已修复该问题（测试中将耗时从 35 秒降至 3.5 秒），修复将随 0.11.2 之后的版本发布，因此请更新到最新版本。如果更新后仍出现卡住的情况，请点击 Log 按钮，导出完整日志，并连同视频时长一起反馈。

jasna

核心功能

避坑指南

适用场景

标签

快速上手

相似推荐