Hello ! I'm not good enough to find by myself where or how we can fix this in code but i identified how to trigger and a ways to resolve the problem the 16xx GC user face when they use Automatic1111 and others programs.
The error every 16xx GC user know well:
«modules.devices.NansException: A tensor with all NaNs was produced in Unet. This could be either because there's not enough precision to represent the picture, or because your video card does not support half type. Try setting the "Upcast cross attention layer to float32" option in Settings > Stable Diffusion or using the --no-half commandline argument to fix this. Use --disable-nan-check commandline argument to disable this check.»
Seems like it happens with Unet when it has to split a prompt who exceed the 75 chunk limit and queue it. With prompt and negative prompt under the 75 everything works fine without the --no-half --no-half-vae --precision full parameters
I get ride of this problem by simply activate the option «Pad prompt/negative prompt to be same length» (pad_cond_uncond) in automatic1111 settings (optimizations). Now i can exceed the 75 without any error
Hope it can help to spot the problem (or help other users looking for a solution to make half precision works with their GC)
Hello ! I'm not good enough to find by myself where or how we can fix this in code but i identified how to trigger and a ways to resolve the problem the 16xx GC user face when they use Automatic1111 and others programs.
The error every 16xx GC user know well: «modules.devices.NansException: A tensor with all NaNs was produced in Unet. This could be either because there's not enough precision to represent the picture, or because your video card does not support half type. Try setting the "Upcast cross attention layer to float32" option in Settings > Stable Diffusion or using the --no-half commandline argument to fix this. Use --disable-nan-check commandline argument to disable this check.»
Seems like it happens with Unet when it has to split a prompt who exceed the 75 chunk limit and queue it. With prompt and negative prompt under the 75 everything works fine without the --no-half --no-half-vae --precision full parameters
I get ride of this problem by simply activate the option «Pad prompt/negative prompt to be same length» (pad_cond_uncond) in automatic1111 settings (optimizations). Now i can exceed the 75 without any error
Hope it can help to spot the problem (or help other users looking for a solution to make half precision works with their GC)
My topic with my test to find it: https://github.com/AUTOMATIC1111/stable-diffusion-webui/discussions/13154