[Bug]: ROCm version turns stupid (super low quality as if skipping steps)

[Nazosan]

Checklist

• The issue exists after disabling all extensions
• The issue exists on a clean installation of webui
• The issue is caused by an extension, but I believe it is caused by a bug in the webui
• The issue exists in the current version of the webui
• The issue has not been reported before recently
• The issue has been reported before but has not been fixed yet

What happened?

The output when using ROCm is severely degraded from what it should be. Even with maximum steps specified it is as if it has use very few (as if 4 or so) steps. This happens on multiple installs in multiple systems. (Please see the greater details below.)

Steps to reproduce the problem

1. Run with ROCm.
2. Generate an image.
3. Resist the urge to vomit.

What should have happened?

It should produce an image of standard quality.

What browsers do you use to access the UI ?

Mozilla Firefox

Sysinfo

sysinfo-2025-04-22-15-01.json

Console logs

################################################################
Install script for stable-diffusion + Web UI
Tested on Debian 11 (Bullseye), Fedora 34+ and openSUSE Leap 15.4 or newer.
################################################################

################################################################
Running on nazo user
################################################################

################################################################
Repo already cloned, using it as install directory
################################################################

################################################################
Create and activate python venv
################################################################

################################################################
Launching launch.py...
################################################################
glibc version is 2.41
Check TCMalloc: libtcmalloc_minimal.so.4
libtcmalloc_minimal.so.4 is linked with libc.so,execute LD_PRELOAD=/lib/x86_64-linux-gnu/libtcmalloc_minimal.so.4
Python 3.10.16 (main, Dec 11 2024, 16:24:50) [GCC 11.2.0]
Version: v1.10.1
Commit hash: 82a973c04367123ae98bd9abdf80d9eda9b910e2
Launching Web UI with arguments: --no-progressbar-hiding --theme dark --listen --medvram
/media/2tbssd/ml/stable-diffusion-webui/venv/lib/python3.10/site-packages/timm/models/layers/__init__.py:48: FutureWarning: Importing from timm.models.layers is deprecated, please import via timm.layers
warnings.warn(f"Importing from {__name__} is deprecated, please import via timm.layers", FutureWarning)
no module 'xformers'. Processing without...
no module 'xformers'. Processing without...
No module 'xformers'. Proceeding without it.
Loading weights [6ce0161689] from /media/2tbssd/ml/stable-diffusion-webui/models/Stable-diffusion/v1-5-pruned-emaonly.safetensors
Running on local URL:  http://0.0.0.0:7860

To create a public link, set `share=True` in `launch()`.
Startup time: 22.5s (prepare environment: 6.8s, import torch: 7.0s, import gradio: 0.9s, setup paths: 4.5s, initialize shared: 0.1s, other imports: 0.4s, load scripts: 0.3s, initialize extra networks: 0.3s, create ui: 0.4s, gradio launch: 1.7s).
Creating model from config: /media/2tbssd/ml/stable-diffusion-webui/configs/v1-inference.yaml
/media/2tbssd/ml/stable-diffusion-webui/venv/lib/python3.10/site-packages/huggingface_hub/file_download.py:896: FutureWarning: `resume_download` is deprecated and will be removed in version 1.0.0. Downloads always resume when possible. If you want to force a new download, use `force_download=True`.
warnings.warn(
Applying attention optimization: Doggettx... done.
Model loaded in 263.3s (load weights from disk: 94.4s, create model: 5.5s, apply weights to model: 87.6s, apply half(): 61.9s, apply dtype to VAE: 2.2s, hijack: 0.5s, load textual inversion embeddings: 0.1s, calculate empty prompt: 10.8s).
100%|███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 150/150 [01:17<00:00,  1.93it/s]
Total progress: 100%|███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 150/150 [01:05<00:00,  2.28it/s]
Total progress: 100%|███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 150/150 [01:05<00:00,  6.82it/s]

Additional information

First, to clarify, I use the term stupid because when I first saw this occur I was on Arch and I also was having issues with KoboldCPP (LLM engine built on llama.cpp) where it would produce output that could only be described as stupid. Failing to follow directions well, almost nonsense output, etc etc. The intriguing thing about that was I also have a Linux Mint installation as a stable backup and when I ran Stable Diffusion within it at that time it was fine (as was KoboldCPP.) So I filed Mint away as my stable backup. I assumed the issue was the ROCm installation itself since Arch is not really supported at all by AMD and is just sort of manually ported by the AUR community.

However, I recently switched to Debian and wanted to try again. Debian is sort of unofficially supported by AMD (they even have official setup instructions for Debian 12 now.) In Debian, KoboldCPP was fine, so I tried StableDiffusion and at first it was fine. I messed something up somewhere along the way of installing a bunch of stuff on the Debian system, so I decided to reinstall StableDiffusion (and accidentally deleted the old one instead of backing it up. Turns out if you accidentally mv a folder to the same name as another folder it just quietly disappears into the void instead.) When I reinstalled StableDiffusion it was broken like this again. So I gave up and tried it in Mint, but it was broken in Mint too. I tried deleting the folder and reinstalling in Mint, but it was still broken. I also tried completely redoing my Debian system from scratch without the stuff StableDiffusion didn't seem to like last time on a fresh clean install and it's still broken. I want to add here that since the Mint setup is intended to be my "stable" backup, I don't update it. Nothing has changed in it since the last time StableDiffusion worked. So first I want to strongly emphasize that this setup was working as-is before and it is now failing where it worked before with a fresh installation.

Now, I want to add here that in both Mint and Debian, KoboldCPP works fine with ROCm. The LLM acts completely normal. The issue I saw outside of StableDiffusion is not present in Debian. Thus I believe it is safe to say the issue here is not the ROCm installation after all. (I just assumed it was since I had such similar results in two different things back on Arch, but after all pytorch is separate.) I've reinstalled several times in either the Mint setup or the Debian setup, but the results are the same every time. I've tried a number of different parameters including the suggested --precision full and --no-half or alternately --upcast-sampling and various combinations of the three with no change in results. Those weren't needed before anyway. (Yes, it worked fine before without any of them. No crash, no errors.) I've tried a completely clean setup with no extensions or themes or anything and I've tried going through every single setting I could think of that could in any way affect output quality. I've tried with the system Python (3.11 in the case of Debian Bookworm, so I was surprised it worked as-is) and with Miniconda3 (since it seems to prefer 3.10.) I've even tried manually installing different pytorch installations into the venv just to see what would happen (even the official AMD pytorch release just to see.) Note that the above logs and etc are all made with just a fresh clean install (I only downloaded a few extensions so they'd be available offline) and the default venv, I am only saying that I tried it. Yes, I even tried it without forcing dark mode on the theme and through all of my eye bleeding I could see the image output was still horrible.

I am not sure if it is related or not, but I should add here that it takes strangely long even to load the model. As in quite a number of minutes (close to six or so for a non-XL model, even longer for XL) even without --medvram or --lowvram. First gen takes incredibly long to start too. Something is definitely going on there, but I don't know if it is related or not. It doesn't take remotely close to as long to load on my old 3070Ti. Even swapping models is still faster than six minutes on it.

I've attached a sample of an image generated with 150 (maximum!) steps using the default SD1.5 model. You wouldn't expect it to be super great since it's only SD1.5, but you'll note that it looks like parts of it were produced at an incredibly low number of steps (like 4 or so) despite me setting the maximum. (No, low numbers don't produce a good image either, I'm just demonstrating that 150 doesn't produce remotely close to what it should.) The prompt was just a simple positive "a person standing in a park and waving" / negative "from behind" (I had to do the negative so it would show the face) which is as simple as it gets.

[Nazosan]

Ok, so this is strange, but I had it working correctly for like two days. I had gone through messing with all kinds of settings and have no clue whatsoever what did it. Now it's broken again. I messed with some setting I guess. I'm not even sure anymore.

On the parts that get really slow sometimes, I've often noticed git --version hanging in the task list for long periods of time sometimes. There are all those warnings about resume_download being depreciated showing up a lot. I tried messing with some of the settings and arguments like --do-not-download-clip and I notice that despite these settings it's still doing a lot of online connections. It really didn't like it if I tried to make it go all offline. I'm starting to wonder if maybe Huggingface or one of the other things it's constantly accessing might be limiting connections. I don't know if that is in any way related or not, but if it requires connections to a server for every single use, that's a problem waiting to happen anyway. If so, perhaps it broke because I was having connection problems earlier and things were timing out a lot.

I'll keep messing with settings and see if I can narrow something down, but at least I have proved it can work in this setup by having it actually do so for a time.