Hanging on 100% issue about stable-diffusion-webui HOT 4 OPEN

I don't know what's causing issue but you got to realize 100% is not 100%

the progress while we showing is only the sampling steps
but there's also other things that happen after
such as the VAE or potentially other post processing
so the true progress is 100%+vae+other post processing

so if you "preemptively stops 1 step before the final"
all that dose is make 100%+vae+other post processing in to 95%+vae+other post processing

if it gets stuck afterwards like in VAE, it's still stuck

I'm guessing the issue is during VAE your system doesn't have enough vram and start using system ram which causes massive slow down
see #11063 (comment)

live preview works differently from normal image, (it essentially decodes the latent space using a different method by default using a cheaper method so it's quicker)

if the issue is with VRAM usage during VAE pahse
there's a couple of things you can try
you can try using TAESD as the final VAE, using TAESD will result in image quality drop but should be much faster and use less VRAM

or you can try https://github.com/pkuliyi2015/multidiffusion-upscaler-for-automatic1111
this can reduce the vram usage during VAE pahse

if the issue is it getting stuck during other post processing then more investigation needs to be done

you should really fill in the issue report with the proper information we requested
like the Sysinfo, if you uploaded that then I can see your settings and what system you're on what graphics card you're using
which may give us clue on what is causing the issue

from stable-diffusion-webui.

@w-e-w Updated Sysinfo
Just checked a few generations, vram is around 4.6~/6.0 during hires then spikes to 5.7~/6.0 on final processing for a 576x640 image upscaled by 2x.

from stable-diffusion-webui.

as expected RTX 2060 with 6GB vram
if it spikes up to 6 then then it's likely that it's actually going into System RAM which can cause slow down

so I think it's highly likely it's caused by not enough VRAM
if you want to test i if this is the case you can you fellow #11063 (comment)
and set CUDA - Sysmem Fallback Policy.to Prefer No Sysmem Fallback
this ment the driver will not try to use system RAM but just ERROR when not enouth VRAM (image gen will fail)

it is possible in your situation --medvram or --lowvram may help
enableing FP8 weight in setting may also help
basically all the settings that reduces vram use may help

from stable-diffusion-webui.

@w-e-w I don't know if it's actually a vram issue. For a normal 50-90 second gen the vram will spike to 5.8~ on final and normal ram will bump up a bit. I just got a generation that took 8+ minutes but it also only spiked to 5.8 and bumped up normal ram a little, so there's no difference there besides the time it takes to finish. Between the 8 minute gen and the gen before it which took 54 seconds, the only difference was the seed and a slight change made to the prompt, the size and everything else was kept the same.

I followed the instructions and turned CUDA - Sysmem Fallback Policy but it didn't do anything different when generating. I even tried making a couple images twice as large as I normally do, capped at vram 5.8 and uses a bunch of ram but no delay and no failure.

from stable-diffusion-webui.