rustc_codegen_gcc VS stable-diffusion

Alternatively, there's another initiative called codegen_gcc which is about using GCC as a backend for the rustc compiler. It's (much) more advanced in Rust support, but I am not sure how easy it would be to use a modified libgccjit from there.

In addition to what others have said about platform support, Rust is also on its way to gaining more platform support through rustc_codegen_gcc, the GCC codegen backend for rustc, as an alternative to the LLVM backend. That means many of the platforms GCC supports will suddenly become available with Rust.

Yeah, rustc_codegen_gcc is a GCC backend for rustc, and its making a lot of good regular progress.

gcc-rs is one of two projects for bringing Rust to gcc. gcc-rs is the more ambitious of the two, with an entirely new frontend. There is also rustc_codegen_gcc (https://github.com/rust-lang/rustc_codegen_gcc) that keeps the rustc frontend, and only swaps out LLVM for GCC at the codegen stage.

Fixing unwinding in release mode is still ungoing. I could use some help here, so anyone with some understanding of unwinding, landing pads or GCC, please come on this issue to discuss this.

Additionally, there is gcc codegen for rustc (https://github.com/rust-lang/rustc_codegen_gcc), which is not a compiler per se, but an alternative code generator, with more architectures supported and other nice things. It's also coming along, but there's still a lot of work to do there too. There's also Cranelift codegen (https://github.com/bjorn3/rustc_codegen_cranelift), which is designed to make debug builds faster, but this is not as exciting/useful as the other 2.

Good idea. I added the tag "help wanted" to the issue.

Also, there are indeed ABI issues, e.g. for 128-bit integers and NaN.

I'm excited about both the backend & the frontend.

There is also a project for rustc to use GCC instead of LLVM for codegen.

https://github.com/rust-lang/rustc_codegen_gcc

Which is a 1-click install of Stable Diffusion with an alternative web interface. You can choose a different approach but this one is pretty simple and I am new to this stuff.

an invisible watermarking of the outputs, to help viewers identify the images as machine-generated.

It sounds like you just want to set up Stable Diffusion to run locally. I don't think your computer's specs will be able to do it. You need a graphics card with a decent amount of VRAM. Stable diffusion is in Python as is almost every AI open source project I've seen. If you can get your hands on a system with an Nvidia RTX card with as much VRAM as possible, you're in business. I have an RTX 3060 with 12 gigs of VRAM and I can run stable diffusion and a whole variety of open source LLMs as well as other projects like face swap, Roop, tortoise TTS, sadtalker, etc...

Use specific GPU on multi GPU systems · Issue #87 · CompVis/stable-diffusion · GitHub

I dealt with this in one of my posts. At least SD 1.1 till 1.5 are all trained on a batch size of 2048. The version pretty much everyone uses (1.5) is first pretrained at a resolution of 256x256 for 237K steps on laion2B-en, at the end of those training steps it will have seen roughly 500M images in laion2B-en. After that it is pre-trained for 194K steps on laion-high-resolution at a resolution of 512x512, which is a subset of 170M images from laion5B. Finally it is trained for 1.110K steps on LAION aesthetic v2 5+. This is easily verified by taking a glance at the model card of SD 1.5. Though that one doesn't specify for part of the training exactly which aesthetic set was used for part of the training, for that you have to look at the CompVis github repo. Thus at the end of it all both the most recent images and the majority of images will have come from LAION aesthetic v2 5+ (seeing every image approx 4 times). Realistically a lot of the weights obtained from pretraining on 2B will have been lost, and only provided a good starting point for the weights.

stable diffusion · CompVis/stable-diffusion@2ff270f · GitHub

Here for example --> https://github.com/CompVis/stable-diffusion