[GH-ISSUE #1200] ROCm相关 #774

New issue

Closed

opened 2026-10-20 10:02:54 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-20 10:02:54 +00:00

Owner

Originally created by @LittleFoxMiMi on GitHub (Sep 6, 2023).
Original GitHub issue: https://github.com/RVC-Project/Retrieval-based-Voice-Conversion-WebUI/issues/1200

尝试在Ubuntu22.04环境下使用PyTorch for ROCm进行训练，发现在网页端无论进行什么操作都会报如下错误：

terminate called after throwing an instance of 'boost::filesystem::filesystem_error'
  what():  boost::filesystem::remove: Directory not empty [system:39]: "/mnt/I/RVC_ROCM/TEMP/miopen-interim-hsaco-14f9-265d-b201-680e"

之后主进程直接退出，更换了python3.10和python3.9问题依旧。读了读代码手动调用模块进行训练，发现所有过程一切正常，除了config文件只能从网页端生成，训练也一切正常：

INFO:azi_mycut:Train Epoch: 1 [0%]
INFO:azi_mycut:[0, 0.0001]
INFO:azi_mycut:loss_disc=nan, loss_gen=nan, loss_fm=nan,loss_mel=nan, loss_kl=nan
DEBUG:matplotlib:matplotlib data path: /mnt/I/RVC_ROCM/python/lib/python3.10/site-packages/matplotlib/mpl-data
DEBUG:matplotlib:CONFIGDIR=/home/littlefoxtail/.config/matplotlib
DEBUG:matplotlib:interactive is False
DEBUG:matplotlib:platform is linux
INFO:azi_mycut:====> Epoch: 1 [2023-09-06 13:26:20] | (0:04:43.465260)
/mnt/I/RVC_ROCM/python/lib/python3.10/site-packages/torch/optim/lr_scheduler.py:136: UserWarning: Detected call of `lr_scheduler.step()` before `optimizer.step()`. In PyTorch 1.1.0 and later, you should call them in the opposite order: `optimizer.step()` before `lr_scheduler.step()`.  Failure to do this will result in PyTorch skipping the first value of the learning rate schedule. See more details at https://pytorch.org/docs/stable/optim.html#how-to-adjust-learning-rate
  warnings.warn("Detected call of `lr_scheduler.step()` before `optimizer.step()`. "
INFO:azi_mycut:====> Epoch: 2 [2023-09-06 13:30:55] | (0:04:35.611698)

查看显卡占用，在batch_size为28的情况下，7900xtx的显存占用为70%，所以本项目其实是完全支持ROCm的。
是否有人遇到和我一样的问题？另外提醒作者，jupyter中的手动代码已经不可用，希望可以更新一下，谢谢。

Originally created by @LittleFoxMiMi on GitHub (Sep 6, 2023). Original GitHub issue: https://github.com/RVC-Project/Retrieval-based-Voice-Conversion-WebUI/issues/1200 尝试在Ubuntu22.04环境下使用PyTorch for ROCm进行训练，发现在网页端无论进行什么操作都会报如下错误： ``` terminate called after throwing an instance of 'boost::filesystem::filesystem_error' what(): boost::filesystem::remove: Directory not empty [system:39]: "/mnt/I/RVC_ROCM/TEMP/miopen-interim-hsaco-14f9-265d-b201-680e" ``` 之后主进程直接退出，更换了python3.10和python3.9问题依旧。读了读代码手动调用模块进行训练，发现所有过程一切正常，除了config文件只能从网页端生成，训练也一切正常： ``` INFO:azi_mycut:Train Epoch: 1 [0%] INFO:azi_mycut:[0, 0.0001] INFO:azi_mycut:loss_disc=nan, loss_gen=nan, loss_fm=nan,loss_mel=nan, loss_kl=nan DEBUG:matplotlib:matplotlib data path: /mnt/I/RVC_ROCM/python/lib/python3.10/site-packages/matplotlib/mpl-data DEBUG:matplotlib:CONFIGDIR=/home/littlefoxtail/.config/matplotlib DEBUG:matplotlib:interactive is False DEBUG:matplotlib:platform is linux INFO:azi_mycut:====> Epoch: 1 [2023-09-06 13:26:20] | (0:04:43.465260) /mnt/I/RVC_ROCM/python/lib/python3.10/site-packages/torch/optim/lr_scheduler.py:136: UserWarning: Detected call of `lr_scheduler.step()` before `optimizer.step()`. In PyTorch 1.1.0 and later, you should call them in the opposite order: `optimizer.step()` before `lr_scheduler.step()`. Failure to do this will result in PyTorch skipping the first value of the learning rate schedule. See more details at https://pytorch.org/docs/stable/optim.html#how-to-adjust-learning-rate warnings.warn("Detected call of `lr_scheduler.step()` before `optimizer.step()`. " INFO:azi_mycut:====> Epoch: 2 [2023-09-06 13:30:55] | (0:04:35.611698) ``` 查看显卡占用，在batch_size为28的情况下，7900xtx的显存占用为70%，所以本项目其实是完全支持ROCm的。是否有人遇到和我一样的问题？另外提醒作者，jupyter中的手动代码已经不可用，希望可以更新一下，谢谢。

bsakaguchi

2026-10-20 10:02:54 +00:00

closed this issue
added the
stale
label

bsakaguchi commented

2026-10-20 10:02:55 +00:00

Author

Owner

@github-actions[bot] commented on GitHub (Apr 30, 2024):

This issue was closed because it has been inactive for 15 days since being marked as stale.

@github-actions[bot] commented on GitHub (Apr 30, 2024): This issue was closed because it has been inactive for 15 days since being marked as stale.