Should I struggle through constant crashes to get my 7900gre with 16gb of vram working, possibly through the headache of ONNX? Can anyone report their own success or offer advice? AMD on linux is generally lovely, SD with AMD on linux, not so much. It was much better with my RTX2080 on linux but gaming was horrible with NVIDIA drivers. I feel I could do more with the 16GB AMD card if stability wasn’t so bad. I currently have both cards running to the horror of my PSU. A1111 does NOT want to see the NVIDIA card, only the AMD. Something about the version of pytorch? More work to be done there.

  • Having a much better time back on Cinnamon default instead of Wayland. Oops!

** It heard me. Crashed again on an x/y plot but due to being away from Wayland I was able to see the terminal dump: amdgpu thermal overload! shutdown initiated! That’ll do it! Finally something easy to fix. Wonder why thermal throttling isn’t kicking in to control runaway? Will stress it once more and clock the temps this time.

Temps were exceeding 115C, phew! No idea why the default amdgpu driver has no fan control but they’re ripping like they should now. Monitoring temps has restored system stability. Using multiple amd/nvidia dedicated venv folders and careful driver choice/installation were the keys to multigpu success.

  • wewbullEnglish
    4·
    3 months ago

    My experience is that AMDs virtual memory system for VRAM is buggy and those bugs cause kernel crashes. A few tips:

    1. If running both cards is overstressing your PSU you might be suffering from voltage drops when your GPU draws maximum power. I was able to run games absolutely fine on my previous PSU, but running diffusion models caused it to collapse. Try just a single card to see if it helps stability.

    2. Make sure your kernel is as recent as possible. There have been a number of fixes in the 6.x series, and I have seen stability go up. Remember: docker images still use your host OS kernel.

    3. If you can, disable the desktop (e.g. systemctl isolate multi-user.target, and run the web gui over the network to another machine. If you’re running ComfyUI, that means adding --listen to the command line options. It’s normally the desktop environment that causes the crashes when it tries to access something in VRAM that has been swapped to normal RAM to make room for your models. Giving the whole GPU to the one task boosts stability massively. It’s not the desktop environment’s fault. The GPU driver should handle the situation.

    4. When you get a crash, often it’s just that the GPU has crashed and not the machine (Won’t be true of a power supply issue). sshing in and shutting down cleanly can save your filesystems the trauma of a hard reboot. If you don’t have another machine, grab a ssh client for your phone like Juice SSH on android. (Not affiliated. It just works for me)

    5. Using rocm-smi to reset the card after a crash might bring things back, but not always. Obviously you have to do this over the network as your display has gone.

    6. Be aware of your VRAM usage (amdgpu_top) and try to avoid overcommitting it. It sucks, but if you can avoid swapping VRAM everything goes better. Low memory modes on the tools can help. ComfyUI has --low-vram for example and it more aggressively removes things from VRAM when it’s finished using them. Slows down generations a bit, but better than crashing.

    With this I’ve been running SDXL on a 8GB RX7600 pretty successfully (~1s per iteration). I’ve been thinking about upgrading but I think I’ll wait for the RX8000 series now. It’s possible the underlying problem is something with the GPU hardware as AMD are definitely improving things with software changes, but not solving it once and for all. I’m also hopeful that they will upgrade the VRAM across the range. The 16GB 7600XT says to me that they know <16GB isn’t practical anymore, so the high-end also has to go up, right?