feat: option to enable vae tiling automatically for large images

[wbruna]

This allows controlling the use of VAE tiling according to the requested image size: tiling will be enabled only for images larger than a given threshold.

Koboldcpp has this same feature. It's mainly useful when the size isn't known at launch time, like in the sd-server, and when the size comes from an input image.

The size is specified by a square image side: --vae-tiling 768 means enabling tiling for images larger than 768x768 - mainly because it's easy to test a NxN image, and more meaningful than something like 'megapixels'. Another possibility could be specifying the size with a string like "768x768". A memory threshold would arguably be better, but harder to implement, since the exact usage depends a lot on the specific backend and flags.

To keep it compatible with current usage, and still avoid an extra flag, the value is optional: --vae-tiling alone is the same as --vae-tiling 1. --vae-tiling 0 also means no tiling.

[stduhpf]

You could already do something like that by playing with --vae-tile-size 48 (48 is 768/16) with vae tiling enabled. I guess it can be nice in some situations to have a way to change the threshold independantly from the tile size.

[wbruna]

You could already do somrthink like that by playing with --vae-tile-size 48 (48 is 768/16) with vae tiling enabled. I guess it can be nice in some situations to have a way to change the threshold independantly from the tile size.

The main issue with this approach is for images right above the tile size. In this case, a 784x784 image, for instance, uses four 48x48 tiles with a huge overlap, where 34x34 would be enough to keep the overlap above 0.5 (and twice as fast).

But maybe reducing the tile size for dimensions with too few tiles (perhaps only 2, since above that the algorithm would probably just reduce the number of tiles anyway) would be a better approach. I can try to come up with a heuristic for that.