sd-extension-system-info VS automatic

I've been using both SD and various LLM on linux without any issue and have done so for months. Windows support is also starting to roll out slowly, with koboldcpp-rocm recently giving me 20-25+t/s for a13B even on windows. you can see what SD performance is like on sites like these. those numbers roughly match what i get on my RX6800 as well (8t/s).

That seems a lot worse than a 2060 SUPER with PyTorch in A1111.

https://vladmandic.github.io/sd-extension-system-info/pages/... (search for 2060 SUPER)

But usually A1111 users use benchmark on this extension https://github.com/vladmandic/sd-extension-system-info

AMD SD = Setup Diaster? it was quite troublesome googling the few linux/amdgpu/rocm/sd vers/configs/params posts online. Also the whole PC may hang during generation which is bad for the harddisk. Your card is way more powerful so may not hang like mine. People are getting 8it/s https://vladmandic.github.io/sd-extension-system-info/pages/benchmark.html

According to system info benchmark, M40 is like 1-2 it/s and P4 is barely better than that.

Anyway to properly "benchmark" the impacts different switches on your image generation speed, it is better to use the benchmarking utility from extension https://github.com/vladmandic/sd-extension-system-info (it also creates a very handy table of results from other users at https://vladmandic.github.io/sd-extension-system-info/pages/benchmark.html for you to compare with.

I can see that the top performance benchmark results on SD WebUI Benchmark Data (using RTX 4090), are obtained through WSL2 running Automatic1111 on a Linux dist and Python 3.10.11, along with PyTorch 2.1.0.dev+cu121 (like benchmark id: 4126)

You should be able to compare based on the published benchmarks, just replicate the settings based on what's reported https://vladmandic.github.io/sd-extension-system-info/pages/benchmark.html

> it won't ever be a viable option

For production workloads, I generally agree. It's an unsupported hack with a questionable future, I wouldn't do anything money-making with it.

However, for tinkering and consumer workloads, it already works pretty well. Enough of cuDNN and cuBLAS work to run PyTorch and in turn, Stable Diffusion with https://github.com/lshqqytiger/ZLUDA - there's even a fairly user-friendly setup process already in https://github.com/vladmandic/automatic .

I was able to get a personal non-ML related project working on my AMD card in just a few minutes, which saved me a lot of development time before I then deployed the production workload on NV hardware (this is probably why AMD pulled the plug on the project - it's almost more of a boost to NV than anything else, AMD really need people to be writing code on ROCm to deploy on AMD datacenter hardware).

While I currently use SD.Next[1], I have tested ComfyUI locally with my AMD card. The UI can be daunting, but you learn quite a great deal about how a Stable Diffusion pipeline works. In addition some innovations and advances find their way into ComfyUI first.

[1] https://github.com/vladmandic/automatic

I used SD.NEXT ( https://github.com/vladmandic/automatic ) and https://civitai.com/models/82098/add-more-details-detail-enhancer-tweaker-lora and epicphotogasm_lastUnicorn

I found this thread on GitHub talking about how this was fixed in the latest version with an optional setting. I tried enabling it, as they mentioned, but it just resulted in an immediate CUDA out of memory error when starting generation. So it seems I'm actually needing the shared memory, which I assume is my issue.

As always, do check out our more detailed changelog, give us a quick install from our Repo, and stop by our Discord Server for any questions or help you may need.

SD.Next

Today I finally wanted to give SDXL a chance, so I set everythin up according to Vladmandic's Wiki https://github.com/vladmandic/automatic/wiki/SD-XL

I'm trying to get SDXL working on Vlad's SDNext, but I keep getting the error in the title when trying to run basic operations. I'm not sure what's going on, I followed his guide for it to a T.

We used an inference container based on SDNext, along with a custom worker written in Typescript that implemented the job processing pipeline. The worker used HTTP to communicate with both the SDNext container and with our batch framework.