sd-extension-system-info VS HIP

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

Is it perhaps because they want people to use HIP?

> HIP is very thin and has little or no performance impact over coding directly in CUDA mode.

> The HIPIFY tools automatically convert source from CUDA to HIP.

1. https://github.com/ROCm/HIP

AMD has released HIP and a tool called HIPIFY which kind of behaves like this but at the source level¹. Rather than try and just translate CUDA to work on AMD compute they are more focused on higher level tooling.

Currently they seem to have a particular focus on AI frameworks and tools like PyTorch/Tensorflow/ONNX. They have sponsored and helped with a lot of PyTorch development for example, so PyTorch support for AMD is much better than it was this time last year².

¹(https://github.com/ROCm/HIP)

²(https://pytorch.org/blog/experience-power-pytorch-2.0/)

> what would be the point for someone to add ROCm support to various pieces of software which currently require CUDA

It isn't just old cards though, CUDA is a point of centralization on a single provider during a time when access to that providers higher end cards isn't even available and that is causing people to look elsewhere.

ROCm supports CUDA through the included HIP projects...

https://github.com/ROCm/HIP

https://github.com/ROCm/HIPCC

https://github.com/ROCm/HIPIFY

The later will regex replace your CUDA methods with HIP methods. If it is as easy as running hipify on your codebase (or just coding to HIP apis), it certainly makes sense to do so.

AMD's equivalent is HIP [1], for sufficiently flexible definitions of "equivalent". I can't speak to how complete/correct/performant it is (I'm just a guy running tutorial/toy-level ML stuff on an RDNA1 card), but part of AMD's problem is that it might not practically matter how well they do this because the broader ecosystem support specifically for the CUDA stack is so entrenched.

[1] https://github.com/ROCm-Developer-Tools/HIP

From what I know, modern GPUs are still programmed with C++ exclusively. See CUDA [0] for Nvidia and ROCm [1] for AMD.

Why is this? Why Rust is not loved there?

[0] https://docs.nvidia.com/cuda/

[1] https://github.com/ROCm-Developer-Tools/HIP

Go ahead and try to ship ROCm code that works on multiple consumer graphics cards on Linux, MacOS, and Windows. As an example of how much AMD cares about it, the installation notes linked to in the readme returns a 404.

The big whoop for ROCm is that AMD invested a considerable amount of engineering time and talent into a tool they call hip. Basically, it's an analysis tool that does its best to port proprietary Nvidia CUDA-style code - which due to various smelly reasons rules the roost - to code that can happily run on AMD graphics cards, and presumably others. Intel has a similar thing going with OneAPI. They've done this whilst working on porting a lot of their code base to the linux AMGPU open source kernel driver, as well.