(Un)stable Diffusion
About a year after everyone else, I gave in to the hype and wanted to play with text-to-image generative models. Here are some issues I ran into while getting it to run on Debian unstable.
I realize that this is probably outdated by next week the time I publish this, but whatever.
First of all, AMDs drivers for GPU compute need to be installed apt-get install rocm-smi rocminfo. Make sure your user is member of the video and render groups (remember to log out and log in again - or just reboot). You can verify that it works by running rocminfo.
I actually went a step further and installed version 5.7.0 of these packages from experimental, as unstable had the somewhat dated version 5.2.3. However at the time of writing, rocm-smi and librocm-smi64-1 (which comes as a dependency) aren’t in experimental anymore. instead there are rocm-cmake and rocm-device-libs-17. I don’t know what to make of these yet.
InvokeAI
The first software bundle I tried was invokeAI. That was pretty straight forward: download the latest release of the installer and run it. It will automatically install all necessary packages and download models.
I don’t know if I butterfingered the selection of which accelerator to install for (CUDA, ROCm, none, “I don’t know”), but it ended up not installing the ROCm libraries. So I moved the .venv folder in the invokeai installation folder and created a new one in its place (python -m venv .venv --prompt InvokeAI). I activated it (source .venv/bin/activate) and pip3-installed as detailed in the “Installing Manually” doc pages, i.e. pip3 install InvokeAI --use-pep517 --extra-index-url https://download.pytorch.org/whl/rocm5.6 at the time of writing.
Once that was fixed, the image generation time went down from about 15-20 minutes to about one and a half minutes for the Stable Diffusion XL model.
AUTOMATIC1111
Because Invoke initially didn’t use ROCm and I hadn’t immediately figured out why, I tried AUTOMATIC1111 in the hopes it would work better.
I cloned the repo, created a virtualenv in the repo folder and ran ./webui.sh. It started installing things into the virtualenv, but quickly gave up with ERROR: No matching distribution found for setuptools>=40.8.0.
My solution to this was to activate the venv in my shell and pip3 install setuptools==69.0.3, followed by the pip command that the webui script had tried to perform, with the addition of --no-build-isolation. In my case this became pip3 install --no-build-isolation torch==2.0.1+rocm5.4.2 torchvision==0.15.2+rocm5.4.2 --index-url https://download.pytorch.org/whl/rocm5.4.2.
This still failed, but with a different error this time: error: invalid command 'bdist_wheel'. This was quickly fixed - pip3 install wheel and now the torch installation succeeded.
The next problem was fatal error: 'limits' file not found. Searching the web for this will find you a number of people telling you to install libstdc++-12-dev, which probably helps if you’re running Ubuntu 22.04. But in my case, that packet already was installed. The real answer is that clang will try to use the libstdc++ headers from GCC, selecting (I assume) the latest version of GCC it can find on your system. You can check which version it tries to use by running clang-11 -v (doesn’t need to be clang-11, just let tab-completion tell you which clang version(s) you have installed)
$ clang-11 -v
Debian clang version 11.1.0-6+b2
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/11
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/12
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/13
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/14
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.5.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/12
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/13
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/14
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/14
Candidate multilib: .;@m64
Selected multilib: .;@m64
Note at the bottom: Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/14. If you don’t have the corresponding version of libstdc++-XX-dev installed, it won’t find the C++ headers. So in this case: apt-get install libstdc++-14-dev
Once I fixed that, AUTOMATIC1111 started up and launched the WebUI in my browser. However, it was using my CPU instead of ROCm/my GPU. But pretending I had a different graphics card by running export HSA_OVERRIDE_GFX_VERSION=10.3.0 in my shell before running ./webui.sh fixed that.